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Abstract 

The  use  of  systems  architeeture,  following  a  set  of  integrated  deseriptions  from  an 
arehitecture  framework,  has  been  well  eodified  in  Department  of  Defense  aequisition  and 
systems  engineering.  However,  in  the  Spaee  Seienee  and  Teehnology  (S&T)  eommunity, 
this  guidanee  and  praetiee  is  not  eommonly  adopted.  This  paper  outlines  an  approaeh  to 
leverage  the  ehanges  made  in  DoD  Arehiteeture  Eramework  2.0  (DoDAE2.0),  and  the 
renewed  emphasis  on  data  and  support  to  aequisition  deeision  analysis.  After 
deeomposing  the  Spaee  S&T  design  lifeeyele  into  phases,  design  milestones  and 
aetivities  using  proeess  models,  a  set  of  DoDAE  preseribed  and  Eit-for-Purpose  views  are 
eonstructed  into  a  reference  implementation  of  a  system  architecture.  This  approach 
attempts  to  make  DoDAE2.0  more  relevant  and  integrated  with  S&T  missions,  the 
decisions  that  are  encountered,  and  facilitates  re-use  with  existing  documentation. 
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TAILORED  SYSTEMS  ARCHITECTURE  EOR  DESIGN  OE  SPACE  SCIENCE  AND 


TECHNOEOGY  MISSIONS  USING  DoDAF  V2.0 

I.  Introduction 

Within  the  Department  of  Defense  the  use  of  systems  arehitecture  has  beeome  a 
neeessary  aetivity  within  systems  development.  In  the  Spaee  Seienee  and  Teehnology 
(S&T)  forum,  where  guidance  on  whether  to  use  and  implement  architecture  permits 
latitudes  and  where  an  urge  to  field  the  system  and  validate  a  capability  is  paramount, 
documentation  and  other  systems  engineering  practices  may  receive  less  attention  than 
they  deserve.  Nonetheless,  the  systems  under  development  are  a  complex  system  of 
systems  and  similar  needs,  goal  and  motivations  that  were  impetus  for  the  system 
architecting  mandates  for  larger  programs  do  exist. 

Given  the  focus  on  rapid  development  and  transition,  if  a  system  architecture 
framework  could  be  developed  and  used  to  increase  visibility  within  the  design,  and  was 
a  useful  tool  for  stakeholders  and  developers  alike  and  was  well  aligned  with  the  design 
effort,  the  reference  model  could  serve  as  a  valuable  tool  throughout  the  development. 

1.1  Problem  Statement 

As  the  goals  for  space  technology  demonstrations  become  more  ambitious,  the 
schedule  and  budget  expectations  are  commensurately  challenging.  Thus,  as 
developmental  systems  are  acquired;  in  many  cases  the  focus  is  to  minimize  waste  by 
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eliminating  any  excess.  Given  the  relatively  finite  nature  of  space  experimental  and 
technology  demonstration  missions  and  the  absence  of  mandates,  a  formal  system 
architecting  model  is  typically  not  developed  or  maintained. 

However,  the  development  and  integration  of  innovative  space  technology  is  a 
technically  complex  environment  that  requires  multiple  systems  operating  in  conjunction 
with  each  other  to  function  correctly.  Additionally  many  S&T  missions  are  “non” 
standard  solutions.  Designs  are  frequently  an  amalgamation  of  previous  systems,  COTS 
and  new  engineering  thus  adding  complexity  from  an  interface  standpoint. 

Given  this  complex  development  environment,  any  tool  or  process  that  promotes 
insight  into  systems  relationships  and  aids  the  maturation  of  system  development  could 
be  a  useful  asset  supporting  decision  making  and  adding  structure  for  the  developer  and 
stakeholder.  However,  a  common  criticism  of  system  architectures  and  the  DoDAF 
model  is  that  they  do  not  support  the  aforementioned  objectives  for  an  architecture. 

Instead,  the  common  perception  is  that  architecting  models  and  products  are 
secondary  end  products  developed  to  satisfy  regulations.  This  split  between  system 
architecting  goals  and  perceptions  beg  the  following  question.  How  is  the  need  for 
architecture,  and  the  information  it  provides,  balanced  with  the  challenge  to  avoid 
superfluous  overhead? 

The  Department  of  Defense  has  tried  to  address  the  classes  of  concerns  in  the 
release  of  DoDAF  version  2.0.  The  recent  revisions  place  a  strong  emphasis  on  having 
the  stakeholders  define  the  objectives  and  implement  the  model  to  service  those 
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objectives.  “Architecture  scoping  must  facilitate  alignment  with,  and  support  the 
decision-making  process  and  ultimately  mission  outcomes  and  objectives.  ”  (1  p.  28) 

Using  the  revised  guidance  and  processes  from  DoDAF  2.0  this  research  will 
offer  concepts  for  a  potential  implementation  of  the  DoDAF  in  a  reference  model  that  is 
aligned  with  purpose,  objectives,  and  roles  for  architecture  in  the  design  of  space  S&T 
system  acquisition.  Additionally,  it  will  attempt  to  provide  some  validation  of  the  model 
offerings  through  historical  examples  demonstrating  the  relevance  of  these  model(s) 
within  the  design  of  a  space  system. 

1.2  Research  Objectives 

The  objective  of  this  research  is  to  investigate  the  ability  to  tailor  the  DoDAF  2.0 
model  for  a  role  that  effectively  supports  the  design  of  space  technology  demonstration 
missions.  This  will  be  accomplished  by  first  identifying  common  developmental  issues, 
decisions  and  critical  information  required  to  support  a  space  S&T  design  and 
development.  Then  using  this  insight,  objectives  and  roles  for  a  systems  architecture 
will  be  developed.  Finally,  views  with  an  accompanying  maturity  model  that  is  aligned 
with  design  and  acquisition  timelines  for  space  systems  will  be  offered  for  potential 
application  that  would  be  consistent  with  DoDAF  2.0  guidance. 

1.3  Research/  Investigative  Questions 

As  stated  above,  the  goal  of  this  work  is  to  develop  a  tailored  architecture  using 
DoDAF  2.0  guidance.  In  order  to  effectively  accomplish  this  certain  questions  regarding 
the  applicability  of  architecting  must  be  investigated.  Initially,  broad  questions  resolving 
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architecture  seope  sueh  as,  “how  systems  arehitecture  eould  be  used  as  a  tool  to  aid 
stakeholders  in  spaee  system  development  or  management”  must  be  posed  to  help  frame 
the  purpose  of  the  effort.  These  inquiries  will  be  followed  with  more  detailed  inquiries 
regarding  deeision  proeesses  and  information  that  may  be  a  relevant  part  of  ereating  a 
useful  tool  for  the  stakeholder.  Finally,  implementation  questions  sueh  as,  “how 
arehiteeture  eould  be  implemented  in  a  eost  and  sehedule  effeetive  fashion,  to  minimize 
the  overhead  assoeiated  with  the  aetivity”  will  be  addressed  to  investigate  streamlined 
methods  for  applieation. 

1.4  Methodology 

The  initials  steps  of  this  effort  were  spent  developing  an  understanding  of  eurrent 
state  of  arehiteeture  within  the  DoD  in  order  to  refine  understanding  of  arehitecture  use 
and  value.  This  was  aeeomplished  by  gathering  data  on  the  DoDAF  framework 
implementation  prior  to  version  2.0.  This  knowledge  was  expanded  by  developing  a 
broad  understanding  of  the  shorteomings  with  the  implementation  of  eurrent  system 
arehitecture  efforts  and  as  the  solutions  that  are  being  suggested  by  the  systems 
engineering  eommunity.  Following  this  effort,  a  signifieant  amount  of  time  was  spent 
with  the  revised  DoDAF  framework  (V2.0)  in  order  to  develop  a  eomprehensive 
understanding  of  how  the  vision  and  implementation  have  ehanged.An  understanding  of 
version  2.0  was  essential  in  the  next  step  of  developing  questions  for  subjeet  matter 
expert  assessment  of  system  arehiteetures.  In  this  phase,  data  was  gathered  from  various 
stakeholder  groups  assoeiated  with  satellite  development  to  answer  questions  regarding 
system  development.  The  questions  were  oriented  to  get  a  better  understanding  of  how 
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information  or  the  lack  thereof  affects  program  decision  making.  Additionally, 
individuals  were  asked  to  identify  project  information  that  is  critical  for  decision  making 
that  is  not  formally  required  or  tracked  but  may  play  a  critical  role  in  decision  making 
throughout  the  development.  This  information  was  used  to  develop  conclusions 
regarding  the  roles  architecture  may  have  in  a  space  S&T  development  environment  as 
well  as  inputs  for  the  types  of  models  that  would  be  useful  for  a  development. 

After  notional  roles  and  purposes  for  S&T  architecture  were  identified,  the  next 
task  was  to  develop  a  streamlined  systems  architecture  framework  using  the  DoDAF  2.0 
model.  This  effort  began  by  first  investigating  standard  program  deliverables  for  a 
development  and  evaluating  both  the  information  contained  within  and  how  these 
products  and  tools  contribute  to  decision  making.  This  information  was  then  synthesized 
with  the  stakeholder  inputs  to  help  develop  a  notion  of  what  views  and  models  would  be 
relevant  given  both  the  goals  mentioned  above  as  well  as  the  inputs  from  subject  matter 
experts. 

After  the  notional  set  of  views  and  models  were  developed,  attention  was  given  to 
looking  at  how  the  models  could  be  implemented  easily  within  the  existing  development 
in  order  to  minimize  overhead.  One  of  the  major  efforts  at  this  point  was  developing  a 
reference  model  for  maturing  the  systems  architecture  views.  The  first  step  in  this  effort 
was  highlighting  possible  uses  for  architecture  views  to  assist  decision  making 
throughout  the  development  timeline.  Once  these  opportunities  were  identified,  the 
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evolution  of  architecture  views  was  carefully  considered  in  order  to  align  model  and  its 
information  with  relevant  activities  in  the  development. 

The  final  step  in  this  effort  was  to  develop  conclusions  regarding  the  effort  that 
was  conducted  and  attempt  to  understand  the  positive  impact  this  effort  could  have  on  a 
development.  This  was  done  by  looking  at  previous  development  and  discussing  how  the 
presence  of  architecture  may  have  helped  avert  issues  encountered  and  suggesting  way 
that  the  architecture  could  be  applied  to  gain  valuable  data  regarding  applicability. 

1.5  Assumptions/Limitations 

This  effort  suggests  methods  and  processes  for  creating  an  architecture  that  is  relevant  for 
a  focused  area  namely  the  design  of  developmental  space  systems.  The  relevance  of  the 
models  proposed  are  inferred  through  the  informal  interviews  regarding  lessons  learned, 
developmental  issues  encountered,  and  processes  previously  encountered  in  development. 

1.6  Research  Implications 

The  S&T  community  has  the  role  not  only  to  demonstrate  the  feasibility  of  a 
technology,  but  to  assist  the  larger  acquisition  community  by  developing  a  knowledge 
base  that  can  be  leveraged  for  an  operational  acquisition.  By  developing  a  construct 
where  critical  system  design  information  is  more  accessible  and  timelier,  one  may 
facilitate  the  transition  of  a  technology  from  the  “laboratory  to  the  field”  by  expediting 
the  development  itself  as  well  as  the  broader  technology  maturity  processes. 
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II,  Literature  Review 


2.1  Current  State  of  DoD  Architecting 

The  use  of  system  architectures  within  the  DoD  acquisition  is  a  well  established 
and  practice  at  this  point  in  time.  The  application  of  system  architecting  has  been 
expanded  well  beyond  its  inception  in  the  1990’s  within  the  Command,  Control, 
Communications,  Computers,  Surveillance  and  Intelligence  Architecture  Framework 
(C4ISRAF).  The  guidance  initially  provided  within  the  DoD  5000  series  documentation 
(2)  in  2003  and  refined  in  both  joint  and  component  instructions  has  largely  required  the 
use  of  systems  architectures  throughout  the  defense  enterprise. 

Although  guidance  to  develop  system  architectures  in  conjunction  with  defense 
acquisitions  is  well  understood,  the  roles,  purpose  and  processes  for  creating,  maturing 
and  using  a  systems  architecture  among  systems  of  various  size  and  scope  are  still  being 
developed  and  refined  at  all  levels  within  the  DoD.  As  organizations  have  attempted  to 
develop  system  architectures  that  are  aligned  with  policies,  significant  obstacles  have 
been  encountered  in  implementing  the  guidance  using  the  DoDAF  construct. 

The  paragraphs  below  discuss  some  of  the  shortcomings  that  have  been 
experienced  with  the  implementation  of  systems  architecture  within  the  DoD  and  offer 
useful  perspective  when  investigating  aligning  architecture  with  development. 

2.1.1  Applicability  of  DoDAF  Across  the  Spectrum  of  DoD  Acquisition 

The  identification  of  the  role  or  purpose  system  architecture  should  play  within  a 
given  effort  needs  proper  definition.  As  Maier  states  in  his  evaluation  of  DoDAF  to 
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ANSI/IEEE  1471  ^  conformance,  organizations  ultimately  using  the  framework  may  have 
different  objectives  for  architeeture  than  the  audience  that  it  was  originally  developed  to 
assist. 


Although  developed  for  acquisition  supervisors  concerned  with  interoperability, 
the  DoDAF  in  practice  is  primarily  used  to  produce  architecture  descriptions 
during  the  early-stages  of  system  development.  (3  p.  19) 

This  observation  illustrates  that  DoDAE  is  not  a  “one  size  fits  all”  tool.  Organizations 

that  implement  DoDAE  need  to  tailor  their  implementation  to  ensure  that  it  provides 

useful  information  to  support  deeision  making.  This  criticism  is  also  validated 

throughout  Volume  1  of  version  2.0  (1)  where  extensive  time  is  spent  discussing  the  need 

for  architeetures  to  be  tailored  to  user’s  needs. 

2,1,2  Alignment  with  Existing  Systems  Engineering  Processes 

At  a  US  Army  sponsored  workshop  entitled  Exploring  Enterprise,  System  of 

Systems,  System,  and  Software  Architectures  in  Mareh  2009,  the  observation  that  was 

offered  during  the  System  of  Systems  working  group  accurately  summarizes  the  poor 

alignment  with  architectures  and  the  systems  engineering  process  that  are  occurring. 

Members  observed  that  there  are  a  lot  of  issues  with  respect  to  the  use  of  the 
DoDAF  for  architecture  development  in  any  genre.  The  good  news  is  that 
architecture  work  is  being  done.  In  many  cases  (but  certainly  not  in  all), 
programs  are  performing  architecture  tasks  as  part  of  their  normal  systems 
engineering  efforts,  but  they  are  not  using  the  DoDAF  for  architecture 
development.  Rather,  it  seems  a  common  practice  is  to  develop  DoDAF  views  to 
meet  DoD  requirements  after  the  initial  architecture  work  has  been  largely 
completed.  Instead  of  an  architecture  development  tool,  the  DODAF  often  is  used 
as  an  “after-the-fact”  documentation  tool.  (4  p.  31) 


*  ANSI/IEEE  1471-2000,  Recommended  Practice  for  Architecture  Description  of  Software-Intensive 
Systems. 
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This  statement  highlights  the  need  to  align  the  arehiteeture  and  the  systems  engineering 
efforts  and  re-enforees  the  inadequacy  of  previous  versions  of  the  DoDAF  construct  in 
facilitating  that  effort. 

2.1,3  Lack  of  Processes  for  Maturing  Architectures 

Research  that  has  examined  the  usability  of  the  DoDAF  framework  cites  the  lack 

of  guidance  in  how  to  mature  DoDAF  products  as  a  central  reason  for  why  the 

architecture  is  not  currently  aligned  with  decision-making  processes  for  a  system. 

Most  fundamentally,  weaknesses  in  the  DoDAF  have  been  identified  as  it 
undergoes  transition  from  a  static,  descriptive  tool  to  a  tool  that  attempts  to 
characterize  dynamic  system  properties.  Little  guidance  is  provided  on  how  to 
translate  requirements  into  the  design  of  the  work  products.  As  promulgated,  the 
DoDAF  does  not  have  a  companion  architecture  development  process  to  take 
advantage  of  its  interconnected  views.  As  a  result,  many  developers  of  DoDAF 
have  treated  it  as  a  contract  deliverable  as  opposed  to  a  central  communications 
tool  in  the  design  process.  ”  (5  p.  14) 


These  issues  highlight  some  of  the  obstacles  that  systems  developers  are  currently 
encountering  in  application  system  architecting  effort.  These  are  major  factors  that  are 
inhibiting  a  more  holistic  use  of  the  DoDAF  framework  during  system  design  and 
development.  If  statements  that  have  been  cited  are  examined  in  the  context  of  each 
other,  an  interesting  conclusion  may  be  drawn.  These  issues  may  be  related  to  the  first 
criticism  this  research  has  postulated.  In  other  words,  because  the  architecting  process 
“as  implemented”  historically  is  not  necessarily  well-suited  for  many  areas  (i.e. 
development),  it  has  not  been  embraced  and  aligned  with  the  standard  practices.  Because 
this  has  largely  not  occurred,  effort  and  processes  have  not  been  adopted  to  mature  these 
models  effectively.  Given  this  thought  process,  relevance  and  utility  become  important 
factors  consider  when  discussing  how  the  architecting  process  should  be  tailored. 
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2,2  DoDAF  Version  2,0 


The  developers  of  DoDAF  have  reeognized  the  aforementioned  shortcomings  as 

well  as  many  others  and  attempted  to  address  many  of  these  concerns  in  Version  2.0  that 

has  been  recently  released.  Version  2.0  places  a  larger  emphasis  on  the  data  contained 

within  the  architecture  or  models  as  opposed  to  the  specific  products  to  display  the  data 

which  were  the  focus  of  previous  generations  of  the  framework.  The  following 

paragraphs  discuss  and  summarize  and  key  differences  found  in  DoDAF  V2.0  Volume  I. 

The  most  profound  change  is  a  migration  to  a  “data-centric  approach”  as  described  in 

Volume  I.  In  plain  terms  what  the  developers  of  this  model  are  trying  to  convey  is  that 

there  is  more  emphasis  on  collection  and  storage  and  use  of  data  needed  for  efficient  and 

effective  decisions  and  less  emphasis  on  the  development  of  specific  architecture 

products.  Ultimately,  the  developers  are  more  concerned  that  the  data  is  accessible  to 

support  decisions,  and  less  concerned  with  the  method  of  presentation  due  to  various 

requirements  of  different  stakeholders,  which  is  a  significant  change. 

The  revised  guidance  also  further  highlights  the  distinction  between  the  types  of 

architectures.  It  begins  by  introducing  the  Enterprise  and  Solution  architecture 

definitions  and  making  a  distinction  between  their  uses  within  the  DoD.  Per  Vol.  I  the 

definitions  of  each  type  of  architecture  are  as  follows: 

Enterprise  Architectures:  A  strategic  information  asset  base,  which 
defines  the  mission,  the  information  necessary  to  perform  the  mission,  the 
technologies  necessary  to  perform  the  mission,  and  the  transitional 
processes  for  implementing  new  technologies  in  response  to  changing 
mission  needs.  EA  includes  a  baseline  architecture,  a  target  architecture, 
and  a  sequencing  plan.  (1  p.  6) 
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Solution  Architectures:  A  framework  or  structure  that  portrays  the 
relationships  among  all  the  elements  of  something  that  answers  a 
problem.  This  architecture  type  is  not  a  part  of  the  DoD  Enterprise 
Architecture,  but  is  used  to  define  a  particular  project  to  create,  update, 
revise,  or  delete  established  activities  in  the  Department.  Solution 
architecture  may  be  developed  to  update  or  extend  one  or  more  of  the 
other  architecture  types.  A  Solution  Architecture  is  the  most  common  type 
of  architecture  developed  in  the  Department.  Solution  architectures 
include,  but  are  not  limited  to,  those  SOA-based  architectures  developed 
in  support  of  specific  data  and  other  services  solutions.  (1  p.  6) 

Another  major  change  in  version  2.0  is  a  significant  revision  of  the  viewpoints  for  model. 

The  three  viewpoints  used  in  previous  version  (e.g.,  Operational,  Technical,  and  System) 

have  been  extended  and  significantly  re-organized.  The  objective  was  to  create  more 

specific  viewpoints  that  relate  to  the  collection  of  architecture-related  data  which  can  be 

organized  as  useful  information  for  the  manager  in  decision-making.  The  revised 

viewpoints  for  DoDAF  2.0  and  a  brief  definition  are  shown  in  Figure  1. 
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Services  Viewpoint 
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Figure  1:  Architecture  Viewpoints  in  DoDAF  V2,0  (1  p,  21) 
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As  can  be  seen  in  Figure  1,  the  views  and  their  roles  have  been  altered 
significantly.  In  addition  to  providing  viewpoint  definitions,  Figure  1  illustrates  the 
relationships  of  the  views  in  the  context  of  each  other.  The  horizontally  depicted  views 
this  ehart  show  how  the  version  2.0  views  relate  to  each  other  in  terms  of  abstraetion, 
migrating  from  capability  oriented  models  downward  to  viewpoints  of  the  underlying 
systems  that  enable  them.  The  vertically  aligned  viewpoints  show  the  vantages  that 
transcend  the  various  levels  of  abstraction  and  illustrate  the  rules,  relationships  and 
standards  that  govern  them.  The  additional  viewpoints  were  added  in  an  attempt  to 
provide  more  flexibility  in  the  DoDAF  model.  The  rationale  for  change  is  that  with  more 
speeific  viewpoints,  organizations  now  have  more  freedom  to  create  architectures  that  are 
aligned  correctly  to  support  the  purposes  that  decision  makers  have  defined  for  them. 

This  one  of  the  reasons  that  the  revised  DoDAF  guidance  does  not  preseribe  any 
mandatory  model  set  for  an  arehitecture.  Instead,  it  chooses  to  eoncentrate  on  the  data 
primary  element  for  the  architecture  and  allows  the  architect  and  stakeholders  select  the 
proper  models  and  views  that  will  help  them  in  accomplishing  the  goals  that  have  been 
identified  for  the  architecture. 

The  notion  of  “tailoring”  the  architecture  highlights  another  important  change  in 
the  DoDAF  guidance.  In  previous  versions,  the  products  within  the  architecture  were 
rigidly  defined.  DoDAF  2.0  has  recognized  this  as  a  shortcoming  with  the  previous 
version  and  adopted  a  philosophy  where  the  models  and  views  need  to  be  selected  to 
support  the  goals  of  architecture.  If  models  don’t  exist  to  support  a  given  purpose  well. 
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“fit  for  purpose”  or  composite  views  can  be  developed  to  help  address  the  stated  need 
and  enhance  the  ability  of  the  architecture  to  be  purpose  driven. 

Finally,  DoDAF  2.0  has  offered  new  processes  to  help  support  the  development  of 
architectures  based  on  the  revised  principles.  This  process  is  data  driven  and  forces  the 
community  using  the  architecture  to  identify  role,  purpose  and  scope  for  the  architecture 
initially.  Then  based  on  these  inputs,  the  process  identifies  the  data  required  to  support 
those  goals.  After  that  has  been  completed,  then  questions  of  how  to  store,  use  and  depict 
the  data  are  addressed  and  agreed  to  by  both  the  architect  and  the  stakeholder.  Once  this 
is  completed,  the  products  are  put  into  use  and  validated  through  feedback  from  the 
stakeholders.  This  process  is  enumerated  in  the  DoDAF  “six  step  process”  which  will  be 
discussed  and  applied  in  later  sections  . 

The  remainder  of  this  research  will  focus  on  implementing  the  revised 
architecting  principles  and  processes  outlined  in  the  DODAF  2.0  guidance  with  the  goal 
of  proposing  a  solution  architecture  reference  model  that  will  address  the  needs  of  the 
space  S&T  development  community.  The  following  section  details  how  the  DODAF  V 
2.0  six  step  evaluation  processes  were  used  to  structure  the  development  of  a  system 
architecture  that  was  tailored  for  the  unique  needs  of  a  space  S&T  development 
environment. 


^  For  a  complete  description  of  the  DoDAF  2.0  Framework,  and  its  revisions  Volume  I  &  II  should  be 
consulted. 
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Ill,  Methodology 


3,1  Introduction 

In  Volume  I  of  DoDAF  2.0,  a  six  step  proeess  (Figure  2)  is  identified  to  assist  the 
development  of  arehitecture.  In  this  proeess  the  first  four  steps  are  foeused  on  the 
development  effort,  and  the  fifth  and  sixth  steps  are  foeused  on  applieation  and 
verifieation.  This  seetion  will  be  struetured  to  demonstrate  how  this  process  was  applied 
to  the  architecting  effort  that  was  conducted.  It  will  also  include  discussion  regarding  the 
effectiveness  of  the  data  gathering  methods  that  were  applied. 


Figure  2  DoDAF  Six  Step  development  Process  (1  p.  51) 


3,2  Decision  Focused  Fit  For  Purpose  Architecture 

In  DoDAF  V2.0  Volume  I,  the  first  step  of  the  development  process  is  to 
determine  the  intended  use  of  the  architecture.  The  first  step  is  described  as  the  process 
for  determining  what  the  purpose  of  the  architecture  will  be  and  determining  the 


14 


objectives,  identify  critical  data  and  success  criteria  for  the  measurement  of  the 
architecture.  This  step  is  typically  driven  by  the  process  owner(s)  and  a  common 
understanding  is  critical. 

Initially,  the  identification  of  a  process  owner  was  an  open  question.  Within  the 
AFSPC  technology  development  community,  adherence  to  DoD  (CJSC62-12E)  and 
AFSPCI  (AFSPCI  10-103)  policy  regarding  system  architecting  is  not  required.  Due  to 
this  lack  of  higher  headquarters  reporting  requirements,  it  was  decided  that  the 
appropriate  owners  would  be  the  program  executives  and/or  milestone  decision 
authorities  for  the  space  segment.  The  measures  of  success  for  a  given  architecture 
would  be  related  to  the  architectures  ability  to  help  effect  the  outcome  of  the  design  under 
development  in  terms  of  completeness,  timeliness  and  ability  to  identify  and  solve  issues 
within  the  development  process.  It  is  important  to  note  that  none  of  these  measures  is 
quantitative.  To  evaluate  the  impact  of  the  architecture  properly,  an  individual  would 
have  to  have  relevant  experience  of  an  S&T  development  in  order  to  properly  assess  the 
architecture’s  ability  to  aid  a  development. 

To  develop  a  cross  functional  understanding  of  how  this  architecture  could  be 
developed,  a  number  of  different  stakeholders  were  surveyed"^.  The  survey  population 
was  cross  functional  group  of  space  system  developers.  Figure  3  illustrates  the  various 


^  Note:  This  statement  does  not  refer  to  AFRL  SE  practices.  Although  there  are  many  collaborative  efforts 
between  AFSPC  and  ARFL  in  the  space  enterprise,  they  adhere  to  different  guidance  regarding  SE 
practices.  Reference  appendix  A  for  a  more  descriptive  explanation  of  the  various  agencies  who  participate 
in  the  S&T  effort 

See  Appendix  C  -  Subject  Matter  Expert  Survey  Form 
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discipline  of  the  sample  population  and  enumerates  the  number  of  individuals  that  were 
surveyed. 

Other 
Mechnical 
Electrical  Power  Systems 
Ground  Command  &  Control 
Flight  Software  /C&DH 
Integration  and  Test 
Systems  Engineering 
Program  Management 

0  2  4  6  8  10 

Number  of  Individuals  Sampled 


Figure  3  Subject  Matter  Expert  Population  Distribution 

The  goal  in  selection  of  the  sample  population  was  to  gather  a  broad  set  of 
different  expertise  involved  in  spacecraft  system  development  in  order  to  have  diverse 
perspective  of  how  architecture  could  be  applied  across  the  various  efforts. 

The  survey  attempted  to  identify  the  goals  of  system  architecting  and  translate  the 
first  few  steps  of  the  DoDAF  process  into  easily  digestible  questions  that  could  be 
answered  regardless  of  system  architecting  expertise.  The  feedback  from  the  initial 
survey  was  largely  fruitless.  Many  of  the  responses  were  vague  and  people  had  difficulty 
providing  concrete  examples  of  the  issues  highlighted  in  the  survey  even  when  they  were 
engaged  in  a  discussion.  As  a  result,  the  approach  for  data  gathering  was  altered. 
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Process  diagrams  were  developed  for  the  various  phases  of  the  development  to  help 
provide  eontext  and  frame  the  diseussion.  Rather  than  providing  another  series  of 
surveys,  interviews  were  eonducted  where  the  process  diagrams  were  used  as  visual  aids 
and  the  questions  in  the  survey  were  approaehed  throughout  the  eonversation.  At  this 
point  the  same  population  was  approaehed  again.  This  aetivity  resulted  in  more  useful 
and  diverse  inputs  regarding  the  purpose,  seope,  data  and  model  applieations  for  spaee 
S&T  arehiteeture. 

After  interviews  were  eompleted,  information  from  the  discussion  was  captured  in 
a  spreadsheet  identifying  the  role  of  the  individual,  lessons  or  suggestions  where 
arehiteeture  eould  help  support  development,  the  data  that  would  be  relevant  and  notions 
of  how  it  may  be  represented  using  either  a  heritage  DoDAF  view  or  a  product/  document 
that  is  eommonly  used  within  a  spaeeeraft  development. 

Using  the  data  obtained,  the  information  was  then  synthesized  to  determine  what 
models  and  data  may  be  a  relevant  part  of  a  spaee  S&T  arehiteeture.  As  ideas  for  views 
and  data  began  to  emerge,  they  were  added  into  a  table  whieh  would  ultimately  beeome 
the  DoDAF  referenee  model  for  spaee  S&T.  An  exeerpt  of  the  model  is  shown  in 


Table  1  below. 
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Table  1  Space  System  Architecture  Model  Extraction 


Mission  Phase 

Relevant  Architecture lUibUilBSim 

H&RBMbI  Function 

MnAoSi 

DODAF 

Model 

Pre  -  system  Acquisition 

Critical  System  Requirments  Capabilties 
/  Contraints  /  Outcomes 

•  Identify  required  program  outcomes  /  measures  of  effectiveness 

-  How  residual  capability  may  be  used  if  deemed  sucessful 

-  Communicate  aspects  of  the  mission  that  must  be  adhered  to  and 
cannot  be  traded  within  the  project 

Draft 

Mission  Plan 

AV-1 

Organizational  Roles 

-  Establish  lines  of  authority 

-  Delegate  project  roles  and  responsibilities 

Mission  Plan 

OV-1 

OV-4 

Schedule 

-  Program  Driving  Schedule  Requirements 

-  Key  schedule  driven  technical  decisions 

Intg  rated 

Milestone 

Schedule 

PV-2 

The  table  that  became  the  reference  model  ^  was  constructed  to  show  each  phase 
of  the  design  process  and  briefly  highlight  the  purpose  for  the  model  or  tool  for  the  given 
timeframe.  It  was  originally  intended  only  be  to  be  a  visual  aid  and  organizational  tool 
while  models  were  being  collected  and  developed.  However,  as  the  effort  progressed  it 
became  clear  that  this  could  be  a  very  useful  “dashboard”  for  the  architecture  helping 
people  to  quickly  understand  the  information  contained  within,  thus  making  it  more 
accessible.  The  reference  model  immediately  helps  the  user  understand  the  purpose  of  the 
various  views,  as  well  as  the  how  a  view's  role  may  have  changed  based  on  the  mission 
phase.  Model  maturity  for  the  phase  is  also  highlighted  to  give  the  user  an  understanding 
of  the  quality  and  completeness  of  the  underlying  data  and  its  susceptibility  to  change. 


^  Note  the  complete  reference  model  is  shown  in  Appendix  D.  Additionally,  each  one  of  the  views  and  the 
rationale  for  inclusion  in  the  reference  model  is  included  in  chapter  4. 
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Finally,  the  reference  model  identifies  the  applicable  documents,  models  or  tools  where 
the  information  resides.  The  reference  model  also  highlights  the  applicable  DoDAF  view 
names  to  help  the  user  easily  understand  the  association  between  the  document  and  the 
DODAF  view.  Specific  explanation  of  each  of  the  column  headings  within  the  reference 
model  are  provided  in  Table  2. 


Table  2  Framework  Heading  Information 


Mission  Phase 

Identifies  the  applicable  mission  phase  for  the 
architecture  models 

Relevant 

Architecture 

Information 

Identifies  information  within  the  view  that  would  be 
useful  to  the  stakeholder 

Purpose/ 

Function 

Brief  statements  describing  the  information  within 
the  model  and  potential  relevance  to  the  design  under 
development 

Maturity 

Lists  document  maturity  at  a  given  phase  in  the 
development: 

-Initial:  document  released  by  responsible  party, 
document  should  not  be  considered  vetted  and  any 
decisions  based  on  documentation  should  be 
validated  with  the  author  for  accuracy 

-  Final:  document  has  been  reviewed  and  revisions 
have  been  coordinated,  reader  should  assume 
information  to  be  accurate  and  complete 

-  Living:  document  regularly  updated  and  posted, 
periodicity  of  updates  should  be  understood, 
questions  regarding  the  currency  of  the  document 
should  be  coordinated  with  owner 

Product(s) 

Identifies  the  program  document  that  contains  the 
relevant  architecture  information 

DODAF  Model 
Reference 

Documents  DODAF  reference  model  number 

Notes: 

Any  other  relevant  information  that  is  required 
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The  goal  of  this  reference  model  ultimately  became  to  provide  a  summary  of  the 
architecture  and  its  maturity  in  the  context  of  the  system  development.  Ideally,  this 
model  would  be  the  first  place  that  an  individual  could  explore  to  help  understand  where 
to  go  in  order  to  look  for  applicable  data  and  gain  some  understanding  with  respect  to  the 
quality/maturity  of  the  information.  Additionally,  depending  on  what  tools  were  used  to 
implement  the  architecture,  it  may  be  used  to  direct  a  user  to  the  information  source. 

After  the  reference  model  was  completed,  a  limited  review  of  the  information  was 
conducted  with  select  individuals  from  the  original  sample  population  who  were  initially 
interviewed  to  verify  applicability  of  the  models  to  the  lessons  that  were  identified.  This 
effort  proved  to  be  helpful  identifying  some  additional  potential  models  and  applications. 
Due  to  time  constraints  a  complete  validation  effort  with  stakeholders  was  not  conducted. 
Additionally,  this  architecture  framework  was  not  taken  and  adopted  for  a  space  S&T 
system  under  development.  Although  models,  meta-data  and  in  some  cases  data  types 
were  identified,  the  process  of  developing  a  construct  gather  and  apply  them  in  an 
architecture  was  not  completed.  This  exercise  would  be  an  excellent  follow  on  activity 
for  additional  research  and  would  provide  useful  insight  regarding  both  the  level  of  effort 
required  and  the  effects  of  the  architecture  on  the  system. 

3,3  Summary 

Table  3  lists  the  architecture  development  steps  from  DoDAF  2.0  and  summarizes 
the  activities  that  were  conducted  in  support  of  developing  the  architecture,  as  well  as 
uncompleted  work  that  could  be  performed  to  refine  this  concept.  The  table  highlights  the 
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activities  that  were  performed;  all  diseussion  of  the  results  is  ineluded  within  ehapter 
four. 


Table  3  Space  System  Architecture  Development  Summary 


DODAF  Development  Step 

Activities  Performed 

1.  Determine  the  intended 
use  of  the  architecture 

Surveys  and  interviews  were  conducted  to  highlight  problems  typically 
encountered  with  space  S&T  acquisitions  and  identify  roles  an 
architecture  could  play  in  resolving  them 

2.  Determiue  the  scope  of  the 
architecture 

The  various  elements  of  the  S&T  space  system  were  examined  and 
boundaries  were  drawn  based  on  stakeholder  inputs 

3.  Determine  data  required 
to  Support  the  architecture 
developmeut 

-  Collected  specific  lessons  regarding  problems  previously  encountered 
with  space  S&T  developments 

-  Synthesized  lessons  by  examining  each  lesson  in  the  context  of 
“applicability  to  system  architecture”  -  what  products  or  processes 
address  the  problem  discussed  in  the  lesson.  Is  this  relevant  to  system 
architecture  and  how? 

4.  Collect,  organize,  correlate 
and  store  architecture  data 

-  Developed  a  model  framework  that  identifies  relevant  architecture  data, 
identifies  purpose(s)  for  the  model  and  discusses  maturity  through  the 
design  life  cycle 

-  Although  candidate  models  or  formats  were  identified  the  architecture 
was  not  implemented,  as  a  result  no  data  was  collected  or  correlated  in  a 
tool 

5.  Conduct  aualyses  in 
support  of  architecture 
objectives 

Not  executed  because  candidate  architecture  was  not  implemented 

6.  Present  results  lAW 
decision  makers  needs 

Not  executed  because  candidate  architecture  was  not  implemented 
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The  application  of  the  DoDAF  process  for  architecture  development  was  a  useful  effort. 

It  provided  valuable  insight  into  the  challenges  that  architects  encounter  in  the  application 
of  architecture  and  underscored  the  need  for  processes  or  methods  to  mature  the 
architecture  during  its  development.  Specific  lessons  and  insights  will  be  discussed  in 
more  detail  in  the  following  chapters  which  review  the  outcomes  of  this  effort  and 
discuss  in  detail  the  proposed  architecture  that  was  developed. 


22 


IV.  Analysis  and  Results 
4.1  Initial  SME  Feedback  on  System  Architecture  Use 

One  of  the  primary  intentions  for  this  effort  was  to  identify  how  system 
architecture  could  be  used  in  an  effective  fashion  for  a  space  system  development  in  the 
science  and  technology  development  arenas.  DoDAF  version  2.0  places  a  renewed 
emphasis  on  stakeholders  identifying  the  role  and  purpose  architecture  should  play  within 
a  system  or  enterprise.  This  is  supported  by  broader  DoD  systems  engineering  reviews 
and  recommendations  which  challenge  users  to  tailor  the  content  and  rigor  of  the  SE 
effort  to  align  with  their  needs. 

In  order  to  develop  specific  ways  a  tailored  architecture  could  support  a 
development,  the  larger  question  of  purpose  and  roles  for  architecture  in  this  environment 
needed  to  be  addressed  first.  As  this  question  was  posed  to  various  individuals,  certain 
themes  emerged  from  the  responses.  Most  individuals  identified  the  use  of  system 
architecture  as  a  tool  to  preserve  information  for  the  future.  A  much  smaller  subset 
identified  the  possibility  of  using  system  architecture  as  a  construct  for  gathering,  storing 
and  maturing  information  to  assist  a  spacecraft  development.  A  summary  set  of 
objectives  for  a  space  S&T  architecture  that  was  decided  upon  based  on  the  responses  is 
shown  below. 

•  Preserving  Critical  System  Development  Information;  S&T  missions  must  ensure 
that  the  “as-built”  system  information,  issues  encountered  and  lessons  learned  are 
preserved  to  help  enable  subsequent  efforts  that  are  derived  from  the  concepts  that 
are  demonstrated 

•  A  communication  tool  to  coordinate  and  integrate  critical  programmatic  and 
technical  information  among  the  various  system  stakeholders  throughout  the 
development  process 
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•  A  construct  for  identifying  how  information  from  various  program  elements 

should  be  matured  over  time  to  result  in  a  system  that  meets  its  mission  objectives 

As  the  eonversations  eontinued  and  a  eommon  understanding  of  topie  was  reaehed,  the 

development  of  boundaries  for  a  spaee  system  arehitecture  evolved  quiekly.  All 

individuals  surveyed  responded  that  boundaries  should  follow  funetional  lines.  However, 

they  also  expressed  there  was  signifieant  information  about  other  systems  that  needed  to 

be  preserved  to  have  the  appropriate  amount  of  eontext.  The  Venn  diagram  (Figure  4) 

illustrates  the  boundary  that  was  ultimately  developed  for  the  arehitecture  example 

illustrated  in  this  work  as  a  part  of  step  two  in  the  DoDAF  six  step  proeess.  Although 

this  arehiteeture  was  focused  on  the  spaeeeraft  element  of  a  S&T  spaee  system,  the  other 

eomponents  of  the  system  eannot  be  ignored.  This  is  espeeially  important  in  the  early 

stages  of  design  where  mission  requirements  are  developed  and  functional 

responsibilities  are  alloeated  to  various  eomponent  areas.  Figure  4  also  helps  to 

highlight  relationships  among  the  various  systems  and  illustrates  some  of  the  information 

themes  or  “meta  data”  from  other  systems  whieh  must  be  preserved  within  the  spaee 

segment  arehiteeture  that  relates  to  the  other  system  elements. 
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Architecture  Boundary 


Component  System  Relationships 
ServicesRequired 

Resources:  Power,  Data,  Mechanical,  Thermal 
Standards:  interface  protocols 
Activities:  procedures  ,  operations  concepts 
Rules:  Performance  constraints,  limitations. 
Conditions:  environmental  constraints 
Measurements:  testing,  models  and 
simulation 


Figure  4  System  Architecture  Boundary  Diagram 


Review  of  the  boundary  that  was  drawn  after  the  fact  resulted  in  an  interesting 
question  regarding  the  boundary  of  the  architecture  that  was  developed:  At  what  level  of 
abstraction  is  it  most  effective  to  develop  an  architecture  for  a  given  space  mission?  If  a 
mission  decision  authority  wanted  to  use  this  tool  to  manage  the  development  across  all 
system  elements,  the  proposed  architecture  would  need  to  be  extended  further.  This  topic 
is  discussed  in  further  detail  within  the  conclusions. 


4,2  Application  of  the  SME  Feedback  into  Principles  of  the  Architecture 

One  of  the  key  insights  from  system  developers  was  the  need  to  synergize  any 
architecture  models  with  the  work  that  was  being  conducted  in  support  of  the  design  to 
enhance  the  ability  of  architecture  to  keep  pace  with  the  maturation  of  the  development. 
As  a  result,  the  goals  associated  with  this  implementation  of  system  architecture  were  to 
use  products  that  are  commonly  created  throughout  the  system  acquisition  process  and 
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make  them  more  effeetive  by  highlighting  their  role  in  the  development  with  the  use  of 
the  framework.  Throughout  the  proeess  of  eross-refereneing  program  doeumentation 
with  DoDAF  model  deseriptions,  several  eases  showed  existing  doeumentation  eould 
satisfy  more  than  one  view  within  the  DoDAF  eonstruet.  This  is  beeause  in  order  to 
achieve  the  intended  purpose  of  the  document  as  they  currently  exist,  they  typically 
leverage  information  from  several  models. 

It  is  important  to  note  that  if  architecture  models  are  going  to  be  developed  and 
maintained  within  the  document  special  attention  needs  to  be  paid  during  the  document 
development  process  to  ensure  that  expectations  for  the  model  are  still  satisfied.  If  a 
given  product  is  going  to  include  or  be  labeled  as  a  “DoDAF  model”,  the  requirements 
for  what  data  should  be  contained  within  the  model  still  must  be  adhered  to.  The  goal  of 
this  approach  is  not  intended  to  re-define  existing  models.  It  is  meant  to  offer 
streamlined  methods  for  model  development  and  maintenance  of  relevant  views.  This 
can  be  accomplished  by  ensuring  the  various  DoDAF  model  data  definitions  and 
requirements  in  Volume  II  are  referenced  and  checked  during  the  document  development 
and  editing. 

Additionally,  in  cases  where  certain  models  are  contained  within  a  given 
document  or  tool  it  is  also  important  to  ensure  that  the  information  is  easily  identifiable 
and  extractable.  This  may  be  accomplished  by  possibly  by  having  detailed  citations  or 
annexes  that  allow  the  user  to  navigate  to  the  documentation  or  providing  specific 
references  to  location  in  the  framework. 

Throughout  the  development  of  architecture  reference  model  significant  attention 
was  also  paid  to  what  information  was  required  to  achieve  the  purpose  outlined  above. 
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As  a  result,  several  “Fit  For  Purpose  or  FFP”  views  were  envisioned  to  help  identify 
program  and  system  information  that  DoDAF  construct  did  not  expressly  identify.  This 
tailoring  process  is  strongly  encouraged  by  the  new  guidance  set  for  forth  in  version  2.0 
to  help  increase  the  relevance  of  the  architecture  to  the  stakeholders  based  on  their  input. 
Example  information  for  the  various  models  that  have  been  proposed  within  the 
architecture  framework  are  included  in  Appendix  B.  Information  contained  within  this 
appendix  is  not  meant  to  imply  syntax  for  the  model  or  a  method  for  it  to  be 
accomplished.  Instead  it  is  offered  as  an  aid  to  provoke  discussion  of  what  information  is 
relevant  for  the  mission  at  hand. 

Using  the  insights  described  above,  the  concepts  for  a  tailored  system  architecture 
reference  model  was  developed  attempting  to  demonstrate  how  these  goals  could  be 
accomplished.  The  following  sub-sections  chronologically  step  through  the  development 
process  and  discuss  how  a  tailored  system  architecture  may  assist  the  invested  parties  in 
achieving  the  desired  outcomes  for  the  mission,  while  preserving  essential  information 
for  the  development  of  follow-on  operations  or  technology  development. 

4,3  Tailored  Space  Architecture  for  S«&T  System  Development 

The  following  sub-sections  will  each  discuss  a  phase  of  the  S&T  design  process 
(pre-system  acquisition,  concept  refinement,  preliminary  design  and  critical  design). 

Each  phase  will  be  introduced  and  accompanied  by  a  process  diagram  highlighting  major 
activities  occurring  within  that  time  frame  will  be  depicted  to  provide  adequate 
contextual  information  to  the  reader.  Then  the  reference  model  for  the  phase  will  be 
presented.  The  model  will  identify  the  various  recommended  program  products  to  be 
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used  within  the  given  phase  and  their  relationship  to  the  DoDAF  models.  It  also 
highlights  important  attributes  of  the  models  at  a  given  point  in  the  development.  In 
every  subseetion  where  a  new  produet  is  introdueed,  summary  information  is  provided 
regarding  the  produet  and  its  intended  use.  Additionally,  a  narrative  or  relevant  lesson 
is  ineluded  below  the  summary  that  helps  validate  the  praetieal  purpose  of  the  produets. 

If  a  produet  update  is  required  in  subsequent  mission  phases  a  diseussion  of  the  how  it’s 
role  has  been  altered  is  diseussed. 

4,3.1  Pre-Systems  Acquisition: 

At  the  onset  of  an  S&T  mission,  many  deeisions  need  to  be  made  quite  early  in 
the  program  that  have  will  have  a  profound  outeome  on  the  aequisition.  In  this  phase 
deeisions  are  made  quiekly  and  may  be  eommunieated  in  an  “ad  hoe”  fashion  whieh  does 
not  allow  parties  who  subsequently  join  the  development  to  appreeiate  the  impetus.  This 
underseores  the  eritieality  for  program  tools  that  help  develop  understanding  regarding 
the  system,  its  assoeiated  risks,  and  teehnieal  ehallenges.  As  ean  be  seen  in  Figure  4, 
after  the  deeision  to  aeeept  a  mission  is  made,  system  development  proeesses 
immediately  follow.  If  these  deeisions  and  proeesses  are  not  well  defined  and 
doeumented  they  will  delay  subsequent  requirements  analysis  and  development  aetivities. 
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Figure  5  Pre-Systems  Acquisition  Process  Diagram 

During  pre-systems  aequisition,  several  areas  were  identified  where  system 
architeeture  models  and  processes  could  help  mature  expectations  for  different  elements 
of  the  program  appropriately  before  a  “mission  acceptance”  decision  is  made.  Table  4 
lists  relevant  architecture  information  identified  throughout  this  research  and  highlights 
rationale  for  the  product  and  maturity.  The  following  section  examines  the  purpose  for 
the  various  products  and  attempts  to  illustrate  how  their  presence  could  provide  valuable 
technical  and  programmatic  insight  to  support  decision  making. 
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Table  4  Preliminary  Design  System  Architecture  Information 


Mission  Phase 

Relevant  Architecture  Information 

Purpose/  Function 

Maturity 

Productfsj 

DODAF 

Model 

Reference 

Pre  -  system  Acquisition 

Integrated  Risk  List 

■  Cross  functional  list  of  risks  compiled  across  integrated  product  team 

Living 

Document 

Consolidated 

Risk  List 

FFP-IA 

Integrated  Risk  Plan 

-  Documentation  outlining  the  program's  risk  posture  and  threshold's 
for  reporting  and  mitigating  risk 

Initial 

Delivery 

Consolidated 

Risk  Plan 

FFP-IB 

Schedule 

-  Program  Driving  Schedule  Requirements 

-  Key  schedule  driven  technical  decisions 

-  Giver  /receiver  relationships  that  span  different  program  elements 

Living 

Document 

Integrated 

Milestone 

Schedule 

PV-2 

Critical  System  Requirements 
Capabilities  /  Constraints  /  Outcomes 

-  Identify  required  program  outcomes  /  measures  of  effectiveness 

-  How  residual  capability  may  be  used  if  deemed  successful 

-  Communicate  aspects  of  the  mission  that  must  be  adhered  to  and 
cannot  be  traded  within  the  project 

Initial 

Delivery 

Mission  Plan 

AV-1 

Organizational  Roles  /  Boundaries 

-  Establish  lines  of  authority 

-  Highlight  system  boundaries  that  will  require  interface  control 
documentation  to  be  developed 

-  Delegate  project  roles  and  responsibilities 

Initial 

Delivery 

Mission  Plan 

OV-1 

OV-4 

Design  Standards  and  Life  Requirements 

-  List  of  regulatory  standards  that  program  is  required  to  comply  with 

-  Understanding  of  nominal  SC  design  life  and  risk  classification  (i.e. 
Class  A,  B,  C...) 

-  List  of  any  international  treaties  that  may  affect  program  decisions 

-  List  of  applicable  technical  standards 

Initial 

Delivery 

Mission  Plan 

STDV-1 

Critical  Program  Documentation 

-  Identify  required  documentation/  information  /models  from  various 
system  developers 

-  Highlights  the  how  many  iterations  are  planned  throughout  the 
document  lifecycle 

-  Identifies  delivery  dates  for  all  information  among  stakeholders 

Living 

Document 

Program 

Documentation 

Maturity  Matrix 

FFP-2 

Open  System  Trades 

-  Description  oi^anized  by  subsystem  of  open  design  trades  and 
decisions  that  need  to  be  completed 

-  Each  trade  should  have  an  owner  and  associated  due  dates  that  are 

aligned  with  program  constraints 

Living 

Document 

Trade/ 

Decision 

tracking  matrix 

FFP-5 

Consolidated  Risk  List  IFFP-IA)  and  Plan  IFFP-IB): 

The  risk  plan  outlines  the  strategy  for  risk  management,  seoring  and  defines  a  risk 
posture  for  the  program.  The  list  provides  an  integrated  view  of  all  the  risks  within  the 
system  in  order  to  effeetively  identify,  manage  and  mitigate  risks  effectively. 

Many  S&T  missions  are  willing  accept  more  program  risks  due  to  the  finite 
nature  of  the  mission.  For  example  many  S&T  missions  accept  single  string  designs 
which  immediately  set  a  certain  risk  posture  for  the  program.  By  defining  major 
program  risks  early  it  helps  to  set  a  frame  of  reference  for  acceptable  risk  within  the 
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program  throughout  the  program  and  makes  it  easier  to  understand  what  level  of  risks 
must  be  mitigated  during  the  design  phase  or  conversely  can  be  accepted. 

Integrated  Milestone  Schedule  lPV-2): 

Prior  to  making  the  decision  to  embark  on  a  mission,  it  is  critical  to  define  the 
elements  of  a  program  that  are  understood  to  challenge  or  constrain  the  trade  space  in 
terms  of  schedule.  An  organized  understanding  of  what  activities  represent  the  highest 
schedule  risk  for  the  development  needs  to  be  compiled  at  the  earliest  stages  of  the 
program  in  order  to  develop  a  feasible  project  timeline. 

Some  components  in  common  small  satellite  designs  routinely  drive  the  ability  to 
begin  system  integration.  The  procurement  of  a  SGLS  transponder  is  a  perfect  example. 
Acquisition  time  for  a  transponder  is  typically  on  the  order  of  16  months.  This  is  due  to 
the  fact  that  specific  crystal  must  be  grown  for  oscillators  which  create  a  wave  form  that 
corresponds  to  an  approved  radio  frequency.  This  process  takes  several  months. 
Additionally,  the  approval  for  a  specific  frequency  is  also  a  lengthy  process  which  will 
drive  schedule  risk.  Therefore,  in  order  to  achieve  total  system  development  timelines  of 
24-  36  months,  critical  decisions  regarding  parts  procurement  will  have  to  occur  in 
advance  of  design  reviews  and  approvals  in  many  cases  to  mitigate  schedule  risk. 
Mission  Plan  IAV-1,  OV-1,  OV-4,  STDV-l); 

During  the  pre-acquisition  phase,  a  Mission  Plan  is  an  umbrella  document  that 
summarizes  the  approach  for  the  mission,  the  organizations  that  will  be  involved  and  the 
outcomes  that  are  desired.  This  document  can  take  various  forms  and  contain  differing 
information  depending  on  the  developing  organization.  While  polling  individuals 
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regarding  this  mission  phase  the  areas  diseussed  below  were  highlighted  as  items  that 
needed  to  be  doeumented  at  the  onset  of  a  mission. 

Capabilities,  Outcomes  &  Measures  of  Effectiveness:  S&T  missions  do  not 
uniformly  have  a  proeess  for  measuring  the  sueeess  of  a  teehnology  on-orbit.  The 
mission  plan  must  identify  how  sueeess  will  be  managed  to  ensure  that  it  appropriately 
flows  into  the  design.  In  many  eases  mission  requirements,  sueh  as  higher  than  planned 
payload  duty  eyeles  and  100%  data  eolleetion  at  the  ground,  emerge  in  later  phases.  If 
these  are  not  appropriately  defined  before  mission  segment  requirements  doeumentation 
is  formulated,  then  the  appropriate  eapability  may  not  exist. 

Design  Standards:  Common  problems  eneountered  within  S&T  developments 
inelude  how  e  standards  should  be  applied  to  aehieve  the  desired  outeomes.  In  many 
eases  the  programmatie  effeets  are  not  appropriately  eonsidered  when  a  deeision  of  how 
to  apply  a  standard  is  made.  For  example,  deeisions  regarding  pieee  part  proeurement 
standards  ean  drive  eomponent  pieee  part  proeurement  eost  by  as  mueh  as  six  times  if 
parts  sereening  is  required  to  meet  standard  (6  p.  11).  Additionally,  the  required 
standards  ean  have  signifieant  effeets  on  lead  time  for  proeurement  based  on  availability 
and  requirements.  These  deeisions  of  how  to  apply  standards  needs  to  be  elosely 
evaluated  and  framed  with  desired  mission  outeomes  and  risks  toleranees  for  a  projeet  to 
strike  a  sueeessful  balanee.  This  aetivity  needs  to  be  done  prior  to  mission  aoeeptanee  to 
avoid  eostly  mis-eoneeptions  and  delays  during  the  requirements  deeomposition  and 
design  phases.  This  point  is  re-enforeed  by  the  faet  that  many  deeisions  regarding 
applieable  standards  may  be  a  result  of  prior  preeedent  and  may  or  may  not  be 
appropriate  for  the  outeomes  that  are  desired  for  the  mission  eurrently  under 
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development.  If  programs  don’t  oritieally  examine  the  required  standards  for  each 
mission,  they  may  unnecessarily  levy  over  restrictive  requirements  such  as  cleanliness 
that  will  end  up  wasting  time  and  money  adhering  to  standards  that  may  not  be  required. 

Design  Life:  In  many  cases  expectations  for  mission  life  are  not  clearly  defined 
or  adhered  to  for  S&T  missions.  Perceptions  that  following  a  demonstration  residual 
capability  may  exist  that  can  be  used  operationally  sometimes  jade  quality  expectations. 
Developers  need  to  clearly  state  what  type  of  system  is  desired  and  not  force  artificial 
expectations  for  design  robustness  that  exceed  the  actual  need. 

Waiver  Authority:  It  is  equally  as  important  to  define  processes  for  requesting 
waivers  to  the  approved  standards  understanding  the  regulatory  processes  that  surround 
them  and  identifying  waiver  authorities  for  the  applicable  standard  if  they  can  in  fact  be 
waived.  In  many  cases  waiver  authorities  do  not  reside  within  the  program  office  (i.e 
Form  813  Environmental  Assessments).  Additionally,  some  regulations  per 
organizational  policy  are  unable  to  be  waived  so  compliance  must  be  achieved  in  the 
mission  design. 

Program  Documentation  Maturity  Matrix  IFFP-2): 

A  common  understanding  of  what  program  documentation  will  be  delivered  and 
how  it  matures  is  common  request  when  discussing  development  lessons  learned.  As 
different  program  elements  interface  with  each  other  the  ability  to  understand  what 
documents  will  be  delivered  and  how  they  will  mature  through  the  course  of  the 
development  is  a  proactive  way  to  enhance  dialogue  surrounding  interfaces  and  on  what 
time  tables  design  trades  must  occur.  This  matrix  can  also  be  used  to  re-enforce 
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expectations  with  respect  to  information  contained  within  the  document  and  develop  a 
common  understanding  among  invested  parties. 

In  many  cases  expectations  for  documentation  vary  significantly,  and  costly  time 
can  be  spent  be  spent  in  review  and  revision  because  a  document  did  not  meet  its 
intended  purpose.  The  use  of  this  view  can  help  baseline  expectations  and  set  the  focus 
for  the  initial  document.  This  view  is  not  intended  to  replace  detailed  requirements  for  a 
document.  However,  drastically  different  ways  of  documenting  system  information  exist 
across  the  space  enterprise.  This  view  can  help  an  individual  understand  where 
information  resides,  as  well  as  how  it  will  mature  through  the  course  of  a  development. 
This  product  should  have  the  widest  distribution  throughout  the  program  so  all  invested 
parties  understand  the  plan  for  documentation  evolution. 

Trade  /  Decision  Tracking  Matrix  IFFP-5): 

From  the  onset  of  concept  development  across  the  various  system  areas,  trades 
emerge  as  the  vision  for  the  mission  is  constructed.  These  trades  will  have  widely 
different  time  horizons  for  decision  making.  As  trades  are  encountered  it  is  important 
within  a  development  to  ensure  that  all  open  trades  are  accounted  for  and  the  deadlines 
for  trade  decisions  are  well  understood.  This  can  help  avoid  hasty  time  based  decision 
making  that  is  not  well  coordinated  or  documented.  In  many  cases  subsystem  engineers 
do  not  fully  consider  the  ramifications  of  how  design  changes  within  their  system  will 
affect  other  systems.  Views  and  processes  that  help  reinforce  this  process  will  help 
mitigate  issues  during  system  integration  and  testing.  A  second  benefit  of  this  view  is 
program  decision  authority  insight.  This  view  will  help  in  ensuring  that  consensus  has 
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been  reaehed  by  all  required  parties  and  provides  useful  insight  leading  to  major  program 
reviews  and  deeisions  regarding  the  amount  of  outstanding  work. 

An  example  of  how  this  produet  ean  be  useful  throughout  the  design  phase  of  the 
aequisition  oeeurred  during  the  development  of  a  flight  software  development  for  a  flight 
software  system.  In  this  ease  the  flight  software  engineering  team  made  the  decision  to 
not  implement  the  concurrent  ability  to  range  and  receive  telemetry  at  the  same  time 
without  consulting  the  larger  systems  engineering,  ground  operations  and  telecom 
engineering  team.  This  implementation  has  serious  implications  for  operations  team, 
especially  in  an  early  orbit  anomalous  situation  post  launch  where  the  ability  to  see 
telemetry  and  range  on  the  vehicle  would  be  highly  desirable  A  product  which  helps  to 
track  program  trades  and  helps  foster  cooperative  decision  making  is  a  useful  asset  for  a 
system  acquisition. 

4,3,2  Concept  Refinement 

Concept  refinement  and  requirements  development  is  often  a  challenging  phase  of 
a  system  development.  In  a  very  short  period  of  time,  the  program  must  adequately 
define  system  requirements  and  the  developer  is  expected  to  understand,  refine 
decompose,  and  allocate  all  of  the  requirements  for  a  given  system.  Within  the  space 
S&T  realm,  this  mission  phase  is  expected  to  be  completed  within  a  very  short  period  of 
time  and  is  often  done  with  high  levels  design  uncertainty  among  system  elements. 
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Elapsed  Time  ~  3-6  months 


Space  S&T  Concept  Refinement 
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Figure  6  Concept  Refinement  Process  Diagram 


Sound  requirements  development  and  refinement  are  eomerstone’s  of  a  development’s 
suecess.  However,  in  many  instanees  this  phase  of  the  mission  has  been  plagued  by  poor 
doeumentation  and  systems  engineering  (6  pp.  27,31).  This  underseores  the  need  for 
information  that  can  help  the  system  developer  and/or  the  program  decision  authority 
with  ways  to  effectively  structure  and  document  decisions  throughout  this  phase. 

There  are  two  distinct  efforts  within  this  phase.  The  first  involves  the  acquiring 
agency  articulating  what  is  required  of  the  system  under  development.  This  effort  should 
heavily  leverage  and  refine  many  of  the  architecture  views  outlined  in  the  previous  phase 
in  particular  the  Mission  Plan.  As  can  be  seen  in  Table  5,  effort  early  in  this  phase  is 
geared  towards  ensuring  that  the  mission  needs,  outcomes  and  standards  are  completely 


36 


articulated.  This  ultimately  results  in  the  delivery  of  a  Spaee  Vehiele  Technical 
Requirements  Document  to  the  system  developer. 


Table  5  Concept  Development  Process  Information 


Mission  Phase 

Relevant  Architecture  Information 

Purpose/  Function 

Maturity 

Product(s) 

DODAF 

Model 

Reference 

Concept  Refinement 

Integrated  Risk  List 

-  Cross  functional  list  of  risks  compiled  across  integrated  product  team 

Living 

Document 

Consolidated 

Risk  List 

FFP-IA 

Schedule 

-  Program  Driving  Schedule  Requirements 

-  Key  schedule  driven  technical  decisions 

-  Giver /receiver  relationships  that  span  different  program  elements 

Living 

Document 

Intgrated 

Milestone 

Schedule 

PV-2 

Critical  System  Requirements 
Capabilities  /  Constraints  /  Outcomes 

-  Identify  required  program  outcomes  /  measures  of  effectiveness 

-  How  residual  capability  may  be  used  if  deemed  successful 

-  Communicate  aspects  of  the  mission  that  must  be  adhered  to  and 
cannot  be  traded  within  the  project 

Final  Delivery 

Mission  Plan 

AV-1 

Organizational  Roles  /  Boundaries 

-  Establish  lines  of  authority 

-  Highlight  system  boundaries  that  will  require  interface  control 
documentation  to  be  developed 

-  Delegate  project  roles  and  responsibilities 

Final  Delivery 

Mission  Plan 

OV-1 

OV-4 

Required  Standards,  Design  Life 
Requirements 

-  List  of  regulatory  standards  that  program  is  required  to  comply  with 

-  includes  Preliminary  LV  Environments  and  Loads 

-  Understanding  of  nominal  SC  design  life  and  risk  classification  (i.e. 
Class  A,  B,  C...) 

-  List  of  any  international  treaties  that  may  affect  program  decsions 

-  List  of  applicable  technical  standards 

Final  Delivery 

Mission  Plan 

STDV-1 

Requirements  Functionally  allocated 
and  derived  foreach  subsystem  and 
component 

-  System  Developers  repsonse  to  the  Technical  Requirements 

Document 

-  Identifies  how  requirements  will  be  allcoated  among  various  systems 

-  Highlights  functional  responsibility  for  each  subsystem 

-  Provides  critical  data  regarding  system  boundaries  and  interfaces 

Final  Delivery 

SV  Requirments 
Specification 

FFP-4 

SV  Technical  Requirements 
Documentation 

-  Complete  list  of  performance  requirements  for  the  Space  System 

-  Delivered  by  the  government  to  the  contractor  /  agency  responsible 
for  space  vehicle  design,  development  and  integration 

Initial 

Delivery 

SV  Technical 
Requirements 

Document 

FFP-3 

Open  System  Trades 

-  Description  organized  by  subsystem  of  open  design  trades  and 
decisions  that  need  to  be  completed 

-  Each  trade  should  have  an  owner  and  associated  due  dates  that  are 
aligned  with  program  constraints 

Living 

Document 

Trade  / 

Decision 
tracking  matrix 

FFP-5 

A  strong  emphasis  throughout  the  beginning  of  this  phase  should  be  to  solicit 
feedback  from  external  agencies.  In  many  instances  this  coordination  can  allow  for  more 
current  requirements  or  standards  to  be  applied  and  included  prior  to  delivery  to  the 
developer  thus  avoiding  confusion  and  iteration  later  in  the  design  review  process. 

Onee  this  information  is  eoordinated,  it  should  eulminate  in  the  delivery  of  a 
comprehensive  technical  requirements  document  being  delivered  to  the  developer  in 
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order  to  convey  system  requirements  in  fashion  that  allow  for  the  agency  to  fully  evaluate 
the  merits  of  a  design. 

Following  the  acceptance  of  a  system  requirements  document  the  second  phase 
begins.  This  is  where  the  developer  to  begin  the  process  of  reviewing,  refine, 
decomposing  and  allocating  the  requirements  to  the  various  subsystems.  This  is  an 
effort  intensive  process  because  complex  interfaces  exist  between  various  systems.  For 
this  reason,  a  common  understanding  of  what  constitutes  a  complete  requirements 
baseline  is  a  useful  benchmark  for  both  the  system  owner  and  the  developer  by  creating  a 
set  of  expectations  to  evaluate  the  completion  of  this  phase. 

Mission  Plan  lAV-l,  OV-1,  OV-4,  STDV-1): 

This  update  should  be  focused  on  clarifying  any  changes  or  omissions  to  the 
critical  system  requirements,  outcomes  and  standards.  The  revision  of  this  document 
should  be  well-circulated  with  external  agencies  to  ensure  that  properly  regulatory 
guidance  and  best  practices  are  implemented.  In  many  cases  revisions  to  guidance  and 
policy  do  not  align  well  with  acquisition  timelines. 

SV  Technical  Requirements  Document  IFFP-3): 

Following  the  validation  of  critical  outcomes  and  standards,  the  acquiring  agency 
should  release  a  comprehensive  systems  requirements  document  that  elaborates  on  the 
desired  outcomes  for  the  system  by  detailing  significant  system  and  subsystem 
requirements.  Some  may  suggest  that  this  element  is  not  required  and  it  should  be  the 
responsibility  of  the  developer  to  derive  from  the  required  capabilities  and  outcomes. 
However,  in  most  cases  the  agency  has  expectations  for  design  development  and  test.  If 
the  developer  is  expected  to  derive  system  or  test  requirements  without  the  guidance  that 
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a  document  comprehensive  requirements  document  would  provide,  serious  discrepancies 
in  the  approaches  taken  with  respect  to  requirements  and  standards  may  be  likely. 

A  good  example  of  the  need  for  detailed  requirement  documentation  can  be  seen 
in  the  development  practices  of  the  DoD  Space  Test  Program.  The  DoD  Space  Test 
Program  will  commonly  take  risks  in  an  accepting  a  single  string  spacecraft  design  due  to 
mass  and  volume  constraints  associated  with  their  space  lift  opportunities.  However,  in 
order  to  mitigate  that  risk,  rigorous  test  requirements  which  may  not  be  typically  required 
for  an  S&T  such  as  full  MIL-STD  1540-E  are  commonly  levied  to  screen  for 
workmanship  issues  and  infant  mortality.  Without  these  detailed  specifications  being 
documented  in  a  technical  requirements  document  to  the  developer,  it  is  unlikely  that 
they  would  adopt  the  preferred  approach.  This  would  result  in  extra  time  and  cost 
expended  in  order  to  come  to  a  consensus. 

Space  Vehicle  System  Specification  (FFP-4): 

This  view  represents  the  complete  set  of  requirements  associated  with  the  system 
and  the  methods  that  will  be  used  to  demonstrate  this  requirement.  The  requirements 
specification  should  demonstrate  how  requirements  are  organized  at  the  system,  sub¬ 
system  and  component  levels.  Recommendations  for  constructing  this  view  are  well 
documented  in  within  the  DISA  Data  Item  Description  (DID).  This  proposed  formatting 
does  allow  tailoring  and  does  not  have  specific  requirements  associated  with  how  the 
document  is  prepared  or  managed.  However,  careful  consideration  should  be  paid  to  the 
approach  that  is  taken. 

Several  interactive  tools  are  available  that  allow  the  user  and  the  developer  to 
trace  requirements  compliance  from  the  component  to  the  system  level.  This  capability 
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significantly  enhances  the  ability  to  work  with  the  information  and  assess  ehanges  as  they 
are  eneountered  throughout  the  design  proeess.  This  is  important  in  the  S&T 
environment  beeause  it  allows  the  individuals  assoeiated  with  design  trades  to  more 
effeetively  understand  the  impaets  of  ehange  throughout  the  development  proeess  in 
eloser  to  real  time.  These  lessons  ean  be  applied  into  final  interfaee  eontrol 
doeumentation  and  used  to  assess  overall  suitability  entering  the  review.  If  issues  are 
eneountered  during  these  aetivities,  mitigations  should  be  developed  prior  to  final  design 
review  to  ensure  that  developers  ean  sueeessfully  transition  from  design  to  integration  at 
eompletion  of  the  review.  These  steps  will  help  all  parties  validate  the  design  and  give 
them  the  requisite  data  to  make  informed  deeisions  when  planning  for  later  phases  of  the 
mission. 

4,3,3  Preliminary  System  Design 

The  name  for  this  phase  ean  be  somewhat  of  a  misnomer.  Even  though  the  first 
iterations  of  the  design  proeess  are  under  development,  many  elements  need  to  be 
eompletely  solidified  at  this  point  in  the  design  proeess.  Additionally,  this  tends  to  be  the 
point  in  the  projeet  where  detailed  interfaee  boundaries  and  speeifieations  must  be 
developed  among  sub-systems  and  systems. 

As  ean  be  seen  in  the  figure  below,  mueh  of  the  effort  expended  throughout  this 
phase  is  dedieated  to  resolving  various  design  deeisions  and  trades.  Tools  that  assist  both 
the  program  developer  and  proeuring  ageney  add  strueture  and  organization  to  this  time 
are  partieularly  important.  Many  of  the  systems  arehiteeture  produets  that  were 
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mentioned  previously  (i.e.  schedule  and  CDRL  list)  within  the  chapter  play  a  significant 
role  in  aiding  this  process. 


Elapsed  Time  ~4-8  months 


Figure  7  Preliminary  System  Design  Process  Diagram 


The  preliminary  design  phase  is  unique  because  although  the  preliminary  design 
review  marks  the  closure  of  the  phase,  some  milestones  that  are  of  equal  or  greater 
importance  must  occur  before  this  happens.  As  individual  subsystem  and  system  designs 
emerge  and  component  trades  for  the  various  systems  are  under  way,  the  schedule 
pressure  of  placing  component  orders  before  the  any  design  review  occurs  in  order  to 
have  a  product  by  the  close  of  the  design  phase  is  looming.  This  can  be  very  difficult 
because  usually  the  components  that  fall  into  this  category  are  some  of  the  most 
important  system  elements  (avionics,  flight  computers  and  transceivers).  The  need  order 
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components  early  also  an  additional  challenge  for  the  systems  engineering  team  to  ensure 
the  requirements  and  interfaces  for  the  component  and  the  systems  are  properly  vetted. 
Models  that  assist  the  program  in  fully  deseribing  and  vetting  the  system  interfaees  and 
doeumenting  them  prior  to  hardware  procurement  decisions  was  the  most  widely 
recognized  applieation  of  system  arehiteeture  throughout  this  mission  phase. 

Table  6  Preliminary  System  Design  Architecture  Information 


Mission  Phase 

Relevant  Architecture  Information 

Purpose/  Function 

Maturity 

Product(s) 

DODAF 

Model 

RefereiKe 

Preliminary  System  Design 

Integrated  Risk  List 

-  Cross  functional  list  of  risks  compiled  across  integrated  product  team 

PDR  Delivery 

Consolidated 

Risk  List 

FFP-IA 

Operational  Environment 

•Matrix  documenting  how  test  requirements  that  have  been  levied  are 
satisfied  with  test  (at  both  the  component  and  system  levels) 

•  Identification  of  the  method  that  will  be  used  to  verify  the 
requirement 

•  Identification  of  any  potential  non-conformances* 

Initial 

Delivery 

Environmental 

Test 

Verification 

Matrix 

FFP-7 

System  Interface  Control  Documentation 

•  This  will  be  a  suite  of  documents,  the  mission  plan  should  identify 
critical  system  boundaries  that  reuqire  a  formal  interface  control 
document 

•  Minimum  Criteria;  SV  -  Ground  and  Payload  to  SV ICD  initial  drafts 
must  be  complete 

•Other  pertinent  ICDs;  LV  -  Spacecraft,  Component  interface  ICD 

Initial 

Delivery 

Interface 

Control 

Documentation 

SV-l/SV-6 

Schedule 

-  Program  Driving  Schedule  Requirements 

-  Key  schedule  driven  technical  decisions 

-  Giver/receiver  relationships  that  span  different  program  elements 

Living 

Document 

Intgrated 

Milestone 

Schedule 

PV-2 

System  /  Sub-system  Design 
Specifications 

•  Partial  Preliminary  understanding  of  system/subsystem  design 

-  Allocation  of  required  system  functions  to  configuration  items 

-  Demonstration  of  how  system  requirements  are  satisfied  by  design 

Initial 

Delivery 

PDR  Design 

Presentation 

SV-5 

Open  System  Trades 

•  Desription  organized  by  susbsystem  of  open  design  trades  and 
decsions  that  need  to  be  completed 

•  Each  trade  should  have  an  owner  and  assocaited  due  dates  that  are 
aligned  with  program  constriants 

Living 

Document 

Trade  / 

Decision 

tracking  matrix 

FFP-5 

Technical  Performance  Measures 

-  Demonstrate  design  peformance  to  critical  program  requirements 
outlined  within  the  requirements  document 

Initial 

Delivery 

Technical 

performance 

budget 

SV-7 

Environmental  Test  Verification  Matrix  (FFP-7): 

A  critical  element  of  component  and  system  design  is  finalizing  the 
environmental  eonditions  that  the  spaee  vehicle  will  experience  throughout  launeh,  upon 
separation  and  in  space.  This  can  be  complicated  in  the  S&T  environment,  beeause  there 
are  instanees  where  aequisition  begins  without  a  eomplete  understanding  of  what  launeh 
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vehicle  environments  will  be  experienced.  Regardless,  of  whether  or  not  the 
environmental  conditions  are  known,  a  best  effort  needs  to  be  made  to  indentify  an 
enveloping  environment  for  testing  as  early  as  possible.  In  many  instances  insufficient 
testing  can  put  undue  risk  to  testing  at  the  space  vehicle  and  drive  cost  later  in  the 
program.  Also,  incorrect  assumptions  regarding  force  limiting  can  lead  to  potential 
susceptibilities.  The  acquiring  agency  should  strive  to  define  environment  at  the  launch 
vehicle  interface  before  any  requirements  are  flown  for  component  level  testing  is 
initiated.  Defining  these  environments  will  pay  large  dividends  later  in  the  program  by 
avoiding  very  extensive  and  costly  tests  and  analysis  later  in  the  program.  If  there  is 
some  level  of  uncertainty  that  cannot  be  resolved  prior  to  component  level  procurement, 
the  acquiring  agency  must  either  accept  the  risk  or  plan  for  significant  cost  growth  later 
in  the  program.  Documentation  that  details  the  tests  environments  for  each  component 
and  the  test  methods  used  for  verification  will  help  in  baselining  expectations.  A  matrix 
that  identifies  verification  methods  is  an  effective  method  to  help  ensure  that  there  is 
consensus  for  accomplishing  this. 

A  previous  satellite  failure  demonstrates  an  example  of  what  can  occur  if 
environments  aren’t  well  understood.  In  this  case,  decisions  were  made  regarding  force 
limiting  launch  vehicle  environments  at  low  frequencies.  Incidentally  in  the  same  range 
where  the  limiting  was  applied  a  launch  vehicle  mode  existed.  Furthermore,  the  telemetry 
received  from  the  launch  vehicle  indicated  that  the  rocket  exceed  its  maximum  predicted 
environment  in  the  same  range.  In  this  case,  when  the  space  vehicle  was  not  able  to  be 
contacted  on  orbit  a  potential  cause  for  failure  was  determined  to  be  incorrect  notching 
strategies  during  vibration  testing.  Although  root  cause  cannot  be  positively  confirmed. 
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data  that  shows  which  environments  the  system  elements  should  be  tested  to  will  allow 
all  agencies  to  understand  the  risk  that  is  being  aecepted  early  and  develop  mitigation 
strategies  if  they  are  required  later  in  the  program. 

Interface  Control  Documentation  (SV-1,  SV-6): 

Properly  defining  and  doeumenting  eritieal  system  interfaces  and  agreeing  on 
formats  is  crucial  in  the  development  of  component  level  speeifieations.  Engineering 
efforts  need  to  be  seoped  to  properly  to  define,  document  and  soeialize  eritieal  system 
interfaees  early  in  the  design  phase  to  avoid  ambiguity  or  incompatibility  between  the 
various  systems.  This  effort  is  espeeially  important  for  systems  that  are  being  developed 
by  different  stakeholders.  In  this  partieular  case  the  ICD  needs  to  be  formally  signed  off 
to  ensure  that  all  invested  parties  have  agreed  to  the  interface.  In  the  design  proeess,  this 
information  may  be  used  as  catalyst  for  developing  consensus  prior  to  reviews.  If 
developers  are  required  to  fully  document  certain  interfaees  before  eertain  eritieal 
component  procurements  are  initiated  pro-activity  and  inter  system  dialogue  could  be 
forced  earlier  in  the  development  process. 

Interfaee  control  documents  also  need  to  be  reviewed  earefully  in  order  to  ensure 
that  the  proper  information  is  included  within  the  doeument.  In  several  instanees 
ambiguous  references  to  existing  standards  have  resulted  in  compatibility  problems. 
Specifically,  when  selecting  command  and  telemetry  data  protocols  particular 
information  needs  to  be  paid  to  ensure  the  view  completely  demonstrates  the  planned 
implementation.  In  the  recent  past,  references  to  standards  such  as  CCSDS  have  given 
system  developers  the  false  security  that  a  format  is  well  understood.  A  way  to  eliminate 
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such  ambiguities  is  to  include  sample  data  references  in  the  views  that  can  be  reviewed 
and  decomposed  by  the  receiving  agency  to  ensure  that  a  consensus  is  reached. 

PDR  Design  Presentation  (DIV-3,  SV-5,  OV-6A,  SV-lOB); 

At  the  culmination  of  this  phase,  the  initial  design  for  each  subsystem  and  the 
system  as  a  whole  should  be  well  understood.  Several  aerospace  system  engineering 
references  such  as  the  Aerospace  System  Engineering  Handbook  documents  detail  all  of 
the  pertinent  design  elements  for  the  various  subsystems.  However,  what  is  often  not 
seen  are  common  views  for  how  the  information  should  be  represented  among  the 
various  subsystems  ensuring  that  the  approach  the  various  developers  have  for  conveying 
information  translates  well  from  subsystem  to  subsystem.  This  is  not  to  say  that  each 
subs-system  needs  to  be  structured  identically.  However,  mandating  certain  views  and 
information  will  increase  the  level  of  understanding  for  those  who  are  not  intimately 
familiar  with  the  systems.  Discussions  with  various  engineers  and  program  managers 
identified  possible  suggestions  what  these  common  views  may  be.  They  are  shown  in 
Table  7. 

Technical  Performance  Budgets  (SV-7): 

In  any  development  critical  performance  parameters  and  limits  should  be  tracked 
throughout  the  course  of  a  design.  The  budgets  should  be  updated  at  regular  intervals  in 
order  for  all  parties  to  understand  how  changes  to  the  budget  throughout  the  design 
process  will  affect  the  larger  system.  The  presence  of  this  data  should  act  as  a  catalyst  to 
assist  in  understanding  if  a  performance  element  is  at  risk  and  mitigation  actions  need  to 
be  pursued. 
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Table  7  Recommended  Design  Review  Common  Views 


Design 

Specification 

Information 

Purpose 

Physical  / 

Functional  View 

-This  view  would  illustrate  all  of  the  components  within  the 
system  and  highlight  their  functional  responsibility  within  the 
system  as  a  whole.  If  the  system  was  software  intensive, 
component  references  may  be  less  important  than  identifying  the 
software  tasks  and  their  relationship  within  the  system. 

-  This  view(s)  would  also  describe  the  different  operating  states  or 
modes  of  the  system. 

Data  Transfer 

View 

Demonstrate  how  data  moves  throughout  the  subsystem/system  in 
both  hardware  and  software.  Illustrate  the  various  ways  that  format 
is  altered  in  the  process. 

Reliability  Views 

-  Analysis’  showing  sub-system  reliability  and  the  supporting 
data/methods  implemented 

-  Subsystem  and  component  flight  heritage  /  pedigree 

-  Identify  any  limited  life  items  within  the  system  to  properly 
identify  constraints  and  risks  associated  with  the  development. 

Technical  Budgets 
/  Performance 

View 

-  Identify  the  system  requirements  and  the  expected  design 
performance,  demonstrate  that  design  has  sufficient  margin  per 
industry  standards  (AIAA)  for  the  given  level  of  maturity 

-  Define  the  level  of  analysis/  simulation  required  to  demonstrate 
the  suitability  of  systems 

The  views  suggested  by  various  SMEs  elosely  resemble  the  various  DoDAF 
viewpoints  for  2.0.  This  suggests  that  the  recommended  views  address  the  different 
aspects  of  design  from  a  fairly  complete  set  of  perspectives. 

4,3,4  Final  System  Design 

At  this  point  in  the  development  a  focused  effort  needs  to  be  made  early  in  the 
phase  to  finalize  interfaces  and  resolve  any  lingering  trades.  As  preliminary  designs  are 
accepted,  a  review  of  each  subsystem  needs  to  be  completed  before  the  remaining 
procurement  decisions  are  finalized  and  production  planning  can  begin. 
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Figure  8  Detailed  System  Design  Process  Diagram 


Reviews  should  be  thorough,  inelude  appropriate  stakeholders  and  mission  assuranee 
bodies  to  ensure  effeetive  deeisions  are  made  prior  to  proeeeding  into  a  review.  In  terms 
of  systems  arehiteeting,  very  little  new  information  is  reeommended  at  this  phase. 
Instead,  the  arehiteetural  models  should  act  as  management  tools  to  ensure  the  design  is 
has  properly  matured  and  open  issues  are  resolved  and  formal  interface  agreements  have 
been  driven  to  closure.  The  table  below  shows  the  system  architecture  framework  and 
maturity  that  is  suggested  for  this  phase. 
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Table  8  Detailed  System  Design  Architecture  Information 


Mission  Phase 

Relevant  Architecture  Information 

Purpose/  Function 

Maturity 

Product(s) 

DODAF 

Model 

Reference 

Detailed  Design 

System  Design  Specifications 

■  Detailed  description  of  "to  be"  system/subsystem  design 

-  Allocation  of  required  system  functions  to  configuration  items 

-  Demonstration  of  how  system  requirements  are  satisfied  by  design 

Final  Delivery 

CDR  Design 

Presentation 

SV-4/SV-5 

Integrated  Risk  List 

-  Cross  functional  list  of  risks  compiled  across  integrated  product  team 

CDR  Delivery 

Consolidated 

Risk  List 

FFP-IA 

Operational  Environment 

-Matrix  documenting  how  test  requirements  that  have  been  levied  are 
satisfied  with  test  {at  both  the  component  and  system  levels) 

-  Identification  of  the  method  that  will  be  used  to  verify  the 
requirement 

-  Identification  of  any  potential  non-conformances* 

Final  Delivery 

Environmental 

Test 

Verification 

Matrix 

FFP-7 

System  Interface  Control  Documentation 

-  This  will  be  a  suite  of  documents,  the  mission  plan  should  identify 
critical  system  boundaries  that  reuqire  a  formal  interface  control 
document 

-  Minimum  Criteria:  SV  -  Ground  and  Payload  to  SV  ICD  initial  drafts 
must  be  complete 

-Other  pertinent  ICDs:  LV  -  Spacecraft,  Component  Interface  ICD 

Final  Delivery 

Interface 

Control 

Documentation 

SV-l/SV-6 

Schedule 

-  Program  Driving  Schedule  Requirements 

-  Key  schedule  driven  technical  decisions 

-  Giver  /receiver  relationships  that  span  different  program  elements 

CDR  Delivery 

Intg  rated 
Milestone 

Schedule 

PV-2 

Integration  Prodcution  Plan 

-  List  of  all  components  under  procurement  and  their  expected  and 
need  dates 

-  List  should  include  all  piece  parts,  miscellaneous  mat' Is,  connectors 
and  required  ground  support  equipment 

Initial 

Delivery 

Integrated 
Production 
Tracking  Tool 

FFP-6 

Technical  Performance  Measures 

-  Demonstrate  design  peformance  to  critical  program  requirements 
outlined  within  the  requirements  document 

Final  Delivery 

Technical 

performance 

budget 

SV-7 

Open  System  Trades 

-  Desription  organized  by  susbsystem  of  open  design  trades  and 
decsions  that  need  to  be  completed 

-  Each  trade  should  have  an  owner  and  assocaited  due  dates  that  are 

aligned  with  program  constriants 

Living 

Document 

Trade  / 

Decision 
tracking  matrix 

FFP-5 

In  order  to  do  accomplish  the  goal  of  closing  lingering  design  decisions  in  an 
effective  manner,  design  documentation  and  models  need  to  be  hnalized  and  circulated 
with  stakeholders  ahead  of  the  review.  Also,  for  critical  interfaces,  simulations  or  test 
with  engineering  models  should  be  considered  to  validate  a  design.  Validation  is 
especially  important  when  considering  interfaces  among  systems  that  are  near  the 
program  critical  path.  The  program  CDRL  and  open  system  trade  data  models  will  help 
assess  if  this  activity  has  been  completed  in  a  timely  manner. 

In  many  cases  for  S&T  missions  the  desire  to  transition  from  design  to  integration 
rapidly  is  paramount  at  this  point  in  the  mission.  If  this  is  desired,  the  element  of 
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production  planning  needs  to  also  be  eonsidered  at  this  juneture  in  the  design.  In  this 
ease,  a  detailed  model  that  shows  how  all  developmental  items  will  proeured,  prepared 
and  tested  to  support  planned  integration  is  eritieal  is  assessing  the  validity  of  the 
approaeh  for  ensuing  phases.  This  plan  model  should  show  how  all  elements  both  flight 
and  non-flight  support  the  baseline  sehedule  or  how  they  are  deficient  in  order  to 
highlight  risk  areas  to  mitigate. 

Integrated  Production  Tracking  Tool  IFFP-6):  Many  instances  in  the  development  of 
systems  where  a  small  and  relatively  inexpensive  system  element  causes  a  significant 
schedule  delay  due  to  unavailability  or  oversight  in  the  product  planning  effort.  In  most 
instances  these  issues  could  have  been  avoided  if  tracking  tools  and  methods  were  used 
to  identify  all  required  parts  (including  ground  support  equipment )  and  track  their 
availability  versus  need  date  for  system  integration.  This  information  will  be  essential  in 
being  able  to  assess  the  readiness  of  a  group  to  transition  from  design  to  integration. 

4,4  Summary 

The  use  of  the  process  models  that  depicted  the  design  lifecycle  and  the  DoDAF  six  step 
process  were  both  essential  parts  of  developing  concepts  for  an  architecture  that  was 
relevant  for  the  design  of  an  S&T  space  system.  The  ability  to  have  subject  matter 
experts  review  and  discuss  the  activities  within  the  phase  was  a  catalyst  for  getting 
insightful  input  on  the  decisions  that  occur  within  a  given  time  period  and  the  data 
required  to  support  them.  These  lessons  translated  well  into  inputs  for  suggested  models 
and  tools  for  architecture.  Additionally,  the  use  of  the  DoDAF  process  helped  provide  a 
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systematic  approach  for  developing  consensus  regarding  the  purpose  of  the  architecture 
first  followed  by  more  detailed  discussions  regarding  the  underlying  data  and  views. 

In  order  to  provide  a  more  complete  description  of  many  of  the  tailored  DoDAF 
models  introduced  within  this  section,  Appendix  B  has  a  series  of  model  descriptions 
developed  in  similar  format  to  the  descriptions  in  Volume  II  of  DoDAF  2.0. 
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V.  Conclusions  and  Recommendations 


5.1  Conclusions  of  Research 

Throughout  the  course  of  researching  and  attempting  to  propose  a  systems 
architecture  that  would  be  suitable  for  a  space  system  development,  several  general 
conclusions  were  reached  regarding  system  architectures  and  their  use  as  well  as  specifics 
insights  regarding  the  suitability  of  a  systems  architecture  for  a  space  S&T  environment. 

Architecture  needs  to  be  purpose  driven.  The  value  of  system  architecture  is  not 
plainly  apparent  to  many  and  the  existence  of  regulatory  guidance  will  not  force 
architecting  to  be  well  aligned  with  engineering.  Unless  architecting  activities  for  a 
given  system  are  given  a  clear  purpose,  people  may  have  difficulty  identifying  how 
architecture  serves  a  purpose  and  are  immediately  useful  and  applicable.  DoDAF  V2.0 
has  come  a  long  way  in  helping  to  change  the  perception  of  architecture  by  being  data- 
centric  and  attempting  to  re-align  system  architectures  to  support  the  decision  making 
processes  within  a  development.  Given  the  novelty  of  version  2.0  and  the  fact  that 
implementation  was  not  completed  as  a  part  of  this  effort  questions  of  supportability  and 
fusion  are  still  largely  left  unanswered. 

Tailoring  systems  architectures  to  meet  the  need  of  a  specific  development  is 
equally  important.  Architecting  emerged  as  a  concept  that  was  essential  for  large 
interoperable  systems  that  required  long-term  sustainment  and  scalability.  In  the  space 
S&T  arena  where  the  long  term  supportability  and  interoperability  aren’t  major  concerns, 
an  architecture  needs  to  be  tailored  to  address  the  issues  that  are  relevant  to  the  systems 

such  as  managing  the  complexity  and  parallel  nature  of  the  development,  providing  tools 
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and  views  to  help  a  developer  see  that  the  system  or  group  of  systems  mature 
appropriately.  The  flexibility  built  into  DoDAF  with  eomposite  and  “Fit  For  Purpose” 
views  are  aspeets  of  DoDAF  2.0  that  have  attempted  to  address  this  shorteoming  and 
were  used  extensively  in  the  development  of  this  reference  model.  However,  the  use  of 
tailoring  also  introduces  a  question  regarding  scope  and  relevance  of  an  architecture.  The 
architecture  concepts  that  were  addressed  in  this  work  were  tailored  to  be  satellite  centric 
vs.  mission  centric  and  were  appropriate  for  a  milestone  decision  authority  that  was 
predominantly  focused  on  a  space  system.  If  the  reference  model  was  to  be  extended  to 
encompass  the  entire  mission,  there  would  certainly  be  other  concerns  that  may  change 
the  underlying  purpose  or  goals.  In  this  case,  the  goals  were  predominantly  developed  to 
support  satellite  design  and  development  and  decision  making  and  were  not  suitable  for 
larger  questions  such  as  assessment  of  overall  mission  readiness.  This  example  illustrates 
that  while  tailoring  an  architecture  to  make  it  relevant  can  help  solve  specific  issues,  one 
must  ensure  that  the  issues  are  aligned  with  what  decision  authorities  and  stakeholders 
expectations  and  that  they  understand  the  limitations  of  what  is  being  developed. 

A  systems  architecture  adopted  for  this  environment  needs  to  be  kept  simple. 
Given  the  finite  nature  of  the  missions  in  a  cost  overrun  or  schedule  constrained  situation, 
documentation  and  excess  deliverables  are  always  one  of  the  first  avenues  people  look  at 
for  relief.  However,  if  the  architecture  models  are  well  aligned  with  existing 
documentation  and  analyses  it  seems  that  two  benefits  emerge.  First,  there  is  little  to  no 
effort  in  producing  data  or  developing  product  simply  for  the  architecture  and  second  the 
product  is  more  accurate.  Less  information  is  lost  or  incorrectly  translated  than  if  a 
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second  model  were  produced.  As  planning  and  requirements  for  documentation  are 
created,  needs  must  be  clearly  conveyed  to  achieved  the  desired  end  result.  Ensuring 
model  requirements  are  conveyed  is  especially  important  when  mapping  program 
documentation  and  describing  it  as  a  specific  DoDAF  model.  In  this  case,  a  concerted 
effort  must  be  applied  to  ensure  that  the  data  requirements  associated  with  each  model  do 
in  fact  reside  in  the  document  and  can  be  extracted.  Mapping  the  product  data 
requirements  to  the  DoDAF  data  model  information  in  Volume  II  may  result  in  some 
additional  effort  early  in  the  development,  but  will  result  in  less  work  than  developing 
and  maintaining  separate  products  through  the  course  of  the  effort. 

Finally,  accessibility  of  the  information  is  extremely  important  regardless  of  the 
tools  or  methods  employed.  Providing  commonly  accessible  areas  where  a  stakeholder 
knows  how  to  access  the  information  will  bolster  the  alignment  of  engineering  and 
architecting.  Both  the  DoD  and  industry  have  tools  that  are  available  to  assist  access,  and 
careful  review  of  several  options  should  be  completed  ensure  that  they  meet  given  needs 
prior  to  selection. 

5.2  Significance  of  Research 

One  of  the  most  important  aspects  of  a  space  science  and  technology 
demonstration  is  timeliness.  If  systems  cannot  be  developed  and  demonstrated  in  a 
timely  fashion  their  applicability  is  diminished  significantly.  While  schedule 
performance  is  very  important  there  is  a  tenuous  balance  exists  between  the  approach 
implemented  to  accelerate  a  development  and  the  level  technical  rigor  and  required.  If 
system  architecting  efforts  can  facilitate  timeliness  by  helping  to  reinforce  decision 
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making  processes  and  eoordinate  appropriate  technieal  review,  their  value  would  beeome 
widely  apparent  and  efforts  to  refine  this  would  be  widely  adopted  aeross  a  wide  variety 
of  systems. 

5,3  Recommendations  for  Action  /  Future  Research 

This  effort  was  primarily  focused  on  understanding  the  DODAF  models 
applieability  and  ehallenges  to  spaee  system  development  leading  to  version  2.0,  how  the 
strategie  ehanges  in  2.0  address  some  of  those  issues  and  offering  a  example  of  how  it 
eould  be  implemented  for  a  given  applieation  (developmental  spaee  systems).  This  effort 
eould  be  augmented  in  several  useful  areas. 

Extending  the  applieation  of  this  arehiteeture  beyond  the  spaee  element  to  all  of 
the  various  systems  would  provide  valuable  insight  for  information  that  is  more  relevant 
to  that  speeific  mission  area  as  well  as  suitability  regarding  some  of  the  “shared” 
elements  that  are  deseribed  in  this  architecture.  This  arehiteeture  eould  also  be  expanded 
further  in  the  development  proeess  to  inelude  integration  and  test. 

Additionally,  the  adoption  and  trial  of  an  architeeting  effort  for  a  developmental 
spaee  system  would  provide  important  feedbaek  on  the  applieability  of  the  suggested 
implementation  that  has  been  proposed  in  this  work.  Implementing  the  reference  model 
would  also  provide  useful  insight  on  some  of  the  praetieal  elements  of  implementation 
that  were  not  addressed  in  the  seoped  in  the  researeh. 
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5.4  Summary 

System  architecture’s  real  value  lies  in  its  ability  to  optimize  the  manner  that 
information  is  exchanged  among  system  elements  in  order  facilitate  development  of 
system  as  a  whole.  The  method  that  is  used  to  achieve  this  is  going  to  be  drastically 
different  based  on  the  system,  its  goals,  stakeholders  and  a  number  of  other  factors.  In 
order  to  make  system  architecture  relevant  and  useful  it  needs  be  tailored  to  account  for 
this  fact.  That  is  not  to  say  each  effort  is  fundamentally  different,  but  it  will  have  unique 
elements.  Additionally,  tailoring  needs  to  extend  beyond  simply  what  information  is 
gathered  in  the  model.  The  tailoring  process  must  be  more  extensively  utilized  to  ask 
other  questions  such  as  how  and  when  the  information  is  gathered.  Finally,  it  must  be 
well  aligned  with  organizational  or  industry-wide  practices  for  development  and 
documentation  so  the  architecture  can  be  readily  adopted. 
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Appendix  A:  S&T  process  Elements  Implemented  by  AFSCI  61-101 


The  process  diagram  shown  below  illustrates  the  translation  of  user  needs  and  strategic 
goals  for  space  into  the  development  of  relevant  S&T  technologies  for  demonstration. 
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Include  robust  solution-finding  process  to  support  PEO  TEO  findings  (incorporates  concepts  fi:otn 
proposed  hixiter  gatherer  process).  SMC  CC  approvedAS  9  as  a  principal  in  PEO  TEO 
Closed-Loop  Feedback:  Solutions  identified  by  PEO  TEO  are  approved  throu^S&T  corporate  process  to 
gain.AFSPC  CC  approval  prior  to  being  implemented  by  AFRL 
AFRL  implementation  leverages  a  broad  set  of  tools  to  reduce  technology  risk  or  improve 

schedule  performance  attributes  of  required  technologies — ^using  them  to  address  PEO  TEO  issues  in  a 
stmctured  format  is  new.  Some  of  these  implementation  options  flowthrough  AFSPC  S&T  process 
programs.  Small  Business  Innovative  Research  bidependent  Research  and  Developmert  (SBIR  IRAD) 
captured  in  S&T  via  feedback  medianism 

AFRL  Focus  Long  Term  ChaEenges  (FLTC)  address  technologies  beyond  the  scope  of  current 
developmaital  engineering  plans — this  supports  HQ  AFSPC  s  long-range  plans  where  SMC  has  not 
presided  detailed  conceptstechnologs'  requirements 

SMC  forum  to  refine  technology  requirements  fi'om  the  System  Program  Director  (SPD)-  supports  S&T 
guidance  developmert  at  HQ  AFSPC.  Opportunity  to  influence  more  than  just  the  space  portfoEo 
S&T  Guidance  is  the  integration  of  all  MAJCOM  direction  into  the  firamework  of  the  C  ommander's 
strategic  vision  and  goals,  including  management  and  process  implementation  functions 
S&T  corporate  process  allows  AFSPC  CC  intent  of  HQ  vector  onaU  issues  sent  to  external  agencies. 

••Ml  existing  activities  in  the  command  receive  feedback  and  use  it  in  the  day-to-day  acUsities 
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Appendix  B:  FFP  Model  Descriptions 


FFP-1  (PV)  Integrated  Risk  Plan  /List:  The  integrated  risk  list  is  tool  that  provides  the 
stakeholder  with  eross  funetional  view  of  program  risk  and  its  effects. 


The  intended  usage  of  the  FFP-1  includes,  hut  is  not  limited  to: 

•  Program  management 

•  Project  planning  including  financial  and  schedule  planning 

•  Risk  Management 

•  Schedule  Management 

Detailed  Description: 

The  Integrated  risk  list  is  a  program  owned  and  managed  model  that  documents  the  risk 
associated  with  various  mission  areas.  It  is  intended  to  provide  program  decision 
authorities  with  a  complete  view  of  risk  at  any  instantaneous  point  in  time.  The 
following  elements  should  be  included  in  the  model:  full  description  of  the  risk,  its 
owner,  probability  that  the  risk  will  be  realized,  impact  if  the  risk  is  encountered,  risk 
exposure  in  terms  of  cost  and  schedule,  mitigation  actions  and  associated  management/ 
trigger  points  for  re-assessment.  This  view  should  be  a  composite  view  of  the  ongoing 
activities  that  are  occurring  to  manage  risk  and  provide  an  understanding  of  the 
intermediate  events  that  result  in  a  risk  being  mitigated  or  realized. 

This  should  be  accompanied  by  a  plan  standardizing  the  way  risks  will  be  identified  and 
outlining  standard  for  risk  ranking  and  evaluation.  (6) 


FFP-2  (SV)  Program  Documentation  Maturity  Matrix:  This  view  enables  all  program 
stakeholders  to  understand  the  various  program  documents,  their  intended  purpose  and 
how  they  mature  through  the  course  of  the  program  lifecycle. 


The  intended  usage  of  the  FFP-2  includes,  hut  is  not  limited  to: 

•  Single  point  of  reference  for  critical  program  documentation  among  stakeholders 

•  Communication  tool  for  system  developers 

•  Common  reference  point  for  program  information  maturity 
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Detailed  Description: 


The  program  documentation  maturity  matrix  is  a  product  that  is  intended  to  help  facilitate 
understanding  among  various  system  element  developers  and  stakeholders  by  providing  a 
common  location  for  all  major  program  documentation,  a  synopsis  of  the  information 
contained  within  the  document  and  data  regarding  how  the  document  is  expected  to 
mature  throughout  the  program  lifecycle.  This  model  will  also  denote  the  information 
owner  and  provide  contact  information.  The  goal  of  this  model  is  to  assist  developers  in 
understanding  how  relevant  information  that  they  may  require  will  mature  throughout  the 
program  and  be  a  catalyst  for  communication  regarding  assumptions  of  documentation 
and  information  contained  within.  This  model  will  need  to  be  maintained  regularly  to 
ensure  that  the  information  is  accurate. 


FFP-3  (SV)  Space  Vehicle  Technical  Requirements  Document:  This  model  is  a 
comprehensive  view  of  all  spacecraft  requirements  that  are  levied  on  the  system 
developed  by  the  acquiring  agency.  This  document  contains  detailed  requirements 
regarding  system  and  subsystem  performance  parameter  that  have  been  derived  from 
mission  requirements. 

The  intended  usage  of  the  FFP-3  includes,  hut  is  not  limited  to: 

•  A  mechanism  for  providing  detailed  expectations  for  system  and  subsystem  standards 
performance,  and  testing 

•  A  tool  for  verification  of  design  suitability  for  system  engineers  throughout  the 
development  process 


Detailed  Description: 

The  space  vehicle  technical  requirements  document  is  a  tool  for  communicating 
acquiring  agency  performance  expectations  to  the  system  developer.  This  model  will 
enable  the  acquiring  agency  to  demonstrate  how  mission  requirements  have  been  derived 
and  translate  into  space  segment  performance  characteristics.  The  goal  of  this  view  is  not 
supersede  any  mission  requirements,  but  provide  the  developer  specific  information 
regarding  government  expectations  regarding  performance,  standards,  testing  and  design 
constraints  in  order  to  more  clearly  present  expectations  for  the  system.  This  should 
assist  the  various  developers  by  narrowing  the  trade  space  on  certain  decisions  and 
identify  areas  of  the  design  where  more  work  is  required  to  achieve  requirements 
compliance. 

This  information  should  be  provided  in  a  hierarchical  format  in  order  to  allow  developers 
to  understand  the  relationships  of  the  various  requirements  to  assist  verification.  If  there 
are  specific  verification  methods  that  are  also  required  they  should  be  stated  within  the 
requirement  as  well.  This  information  needs  to  be  unequivocal.  In  other  words  if  it  is  not 
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truly  required,  or  the  aequiring  ageney  is  willing  to  trade  the  approach  it  should  be 
communicated  using  a  different  mechanism. 


FFP-4  (SV)  Requirements  Verification  Matrix:  This  model  is  the  developer’s  response 
to  all  of  the  requirements  that  have  been  requested.  It  is  an  extension  of  the  technical 
requirements  document  that  addresses  all  requirements  and  how  they  are  satisfied 


The  intended  usage  of  the  FFP-4  includes,  hut  is  not  limited  to: 

•  Technical  Management 

•  A  tool  for  communicating  developer’s  vision  regarding  how  design  requirements  will 
be  addressed  within  the  system 


Detailed  Description: 

This  model  represents  the  entire  requirements  set  for  the  system  element.  It  should 
include  all  government  requirements  and  properly  extend  them  by  providing  complete 
requirements  derivation  from  the  component  level.  The  verification  matrix  should  have 
identified  all  required  functions  for  the  system  and  allocated  them  to  appropriate  sub- 
system(s). 

The  model  should  be  developed  in  an  interactive  environment  that  allows  the  developer 
and  the  acquirer  to  work  collaboratively  within  the  construct  and  facilitate  understanding 
how  the  requirements  are  organized  and  verification  methods  at  the  component,  sub¬ 
system  and  system  levels.  There  are  several  different  commercial  tools  and  instructions 
that  can  be  utilized  to  implement  this  model. 


FFP-5  (SV/PV)  Open  System  Trades:  This  model  provides  a  mechanism  for  tracking 
the  progress  of  various  system  and  subsystem  trades  throughout  a  program. 


The  intended  usage  of  the  FFP-5  includes,  hut  is  not  limited  to: 

•  Program  Management 

•  Systems  Engineering 

•  A  tracking  tool  for  the  various  system  developers  to  identify  the  ongoing  trades  that 
are  occurring  within  a  system 


Detailed  Description: 
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This  model  provides  an  interaetive  environment  for  developers  to  list  the  earious  trades 
that  are  oeeurring  within  their  area  of  responsibility  and  eommunieate  how  this  trade  may 
affeet  related  systems.  This  tool  would  also  provide  the  system  aequirer  insight  regarding 
how  the  various  trades  are  progressing  towards  completion  within  the  various  stages  of 
the  mission  design  phase.  This  will  provide  important  verification  that  due  diligence  has 
been  completed  as  procurement  decisions  occur  in  parallel  with  system  design.  This 
view  should  identify  the  trade  and  the  owner,  the  related  affected  parties  and  should  have 
certain  requirements  for  closure  of  the  trade  that  extend  beyond  the  responsible  engineer 
for  the  system.  Notation  regarding  where  the  outcome  of  the  trade  will  be  documented 
should  be  identified.  Information  regarding  the  scheduling  of  the  trade  should  be 
presented  including  when  the  trade  was  opened,  an  expected  date  for  completion  and  an 
actual  date  for  the  closure  of  the  trade.  This  information  will  assist  the  acquiring  agency 
in  understanding  how  the  design  will  mature  over  time. 


FFP-6  (SV/PV)  Spacecraft  Production  Planning  Tool 


The  intended  usage  of  the  FFP-6  includes,  hut  is  not  limited  to: 

•  Program  management 

•  Schedule  management  and  production  planning 

•  Risk  Management 


Detailed  Description: 

The  space  vehicle  technical  requirements  document  is  a  tool  for  helping  to  track  all  of  the 
required  materials  for  integration  of  the  spacecraft  including  piece  parts  connectors, 
facilities  and  support  equipment.  The  goal  of  this  model  is  to  actively  track  all  parts 
elements  against  an  integration  need  date  and  avoid  unnecessary  work  delay  on  account 
of  secondary  materials  being  missing. 

This  model  should  identify  all  resources  required,  their  associated  need  date,  anticipated 
delivery  date  and  whether  or  not  they  have  been  transferred  to  program  inventory.  This 
view  should  highlight  products  that  either  have  a  short  slack  or  may  affect  the  ability  to 
delay  integration.  This  tool  should  highlight  this  information  for  the  user  in  order  to 
promote  early  mitigation. 

This  model  should  be  used  for  both  as  an  interactive  tool  for  program  planning  as  well  as 
providing  a  comprehensive  insight  regarding  whether  or  not  the  physical  resources 
required  for  this  period  have  been  planned  adequately.  This  model  can  also  be  extended 
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to  include  other  required  resourees  such  as  procedures  and  track  quantities  for  parts  that 
may  be  in  short  supply  or  have  a  limited  shelf  life. 


FFP-7  (SV)  Environmental  Test  Verification  Matrix 


The  intended  usage  of  the  FFP-7  includes,  hut  is  not  limited  to: 

•  Systems  Engineering 

•  Risk  Management 


Detailed  Description: 

The  environmental  test  verifieation  matrix  illustrates  how  environmental  requirements 
have  been  satisfied  at  the  eomponent  and  system  levels.  This  matrix  should  include 
information  regarding  the  qualifieation  method,  for  eaeh  environment,  the  environments 
experieneed,  as  well  as  speeifie  data  regarding  the  repetitions  and  limits  with  the 
assoeiated  test. 

This  view  should  present  a  elear  pieture  of  if  the  system  has  been  tested  to  the  expeeted 
environments  and  deviations  that  may  exist.  This  will  allow  the  systems  engineering  and 
risk  management  personnel  to  properly  assess  the  risk  of  system  failure  during  test  or 
launeh  and  early  operations. 
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Appendix  C:  Subject  Matter  Expert  Survey 


How  a  Tailored  Systems  Architecture  Aides  in  Decision  Making  for  Space  Science  and  Technology 

Missions 


One  of  the  common  questions  that  is  posed  when  the  topic  of  systems  architectures  is  discussed  is  ,”what  is 
this  for  and  how  does  it  assist  a  program?”  A  commonly  cited  problem  in  systems  architecting  is  the 
divorce  between  the  architecting  effort  and  the  decision  making  that  surrounds  the  program. 

The  goal  of  this  research  is  to  look  at  the  systems  architecture  development  process  (specifically  DoDAF 
2.0)  and  determine  how  it  is  applicable  to  systems  under  development  in  the  Space  S&T  community. 

Historically,  the  DoDAF  process  is  very  thorough  and  is  generally  geared  to  more  operational  systems  that 
are  part  of  a  larger  system  of  systems.  In  Space  S&T  acquisitions  the  finite  mission  length  and  fiscal 
constraints  make  a  traditional  DoDAF  architecture  impractical.  Although  full  systems  architecture  may 
not  be  a  feasible,  it  is  my  assertion  that  using  a  tailored  set  of  architectural  views  to  aid  decision  making 
throughout  the  course  of  a  development  may  aid  missions  ensuring  that  the  correct  information  is  available 
to  make  appropriate  decisions.  Additionally,  defining  the  requisite  information  to  make  the  decision  could 
assist  both  the  developer  and  the  manager  in  communications  and  expectation  management  for  the 
development. 

If  you  have  this  worksheet  I  would  like  to  have  an  informal  discussion  with  you  regarding  key  decisions 
within  a  program  development.  I  would  like  to  draw  upon  your  experiences  both  (positive  and  negative) 
regarding  key  decisions  and  how  they  affect  space  Science  and  Technology  acquisitions.  My  objective  is 
to  look  at  decisions  that  profoundly  affect  a  program  during  the  design  process,  but  may  not  be  formally 
identified  as  key  decision  points  in  the  development  process.  My  objective  is  to  sample  those  examples, 
critically  examine  what  data  would  be  required  to  appropriately  make  the  decisions  and  in  turn  develop  a 
guide  for  key  system  data,  products  and  documentation  that  is  needed  during  the  design  process  and 
develop  a  model  for  when  it  should  be  delivered  in  the  context  of  a  development. 

Questions  of  Interest: 

What  decisions  have  a  profound  effect  on  the  program  that  may  not  be  formally  tracked  or 
recognized  in  a  program  design/development  timeline? 

o  What  are  the  products/  information  required  to  make  the  decision? 

■  Is  the  “producf  ’  commonly  developed  or  would  this  be  a  new  product? 

o  Are  there  any  recommendations  regarding  review  or  signature  to  increase  the  awareness 
of  the  decisions 

o  When  in  terms  of  project  milestones  should  the  decision  and/or  data  be  required? 
o  Do  you  have  specific  examples  of  impacts  (positive  or  negative)  of  how  this  decision 
affected  the  program? 

■  Late  decisions 

■  Decisions  made  without  the  appropriate  information 

■  Deferred  decisions 

What  do  we  do  right  from  a  decision  making  standpoint? 

What  are  good  examples  of  situations  where  we  make  sound  decisions  based  on  data  presented  in  a  timely 
fashion? 
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Appendix  D:  Proposed  S«&:T  Architecture  Framework 


Mission  Phase 

Relevant  Architecture  Information 

Purpose/  Function 

Maturity 

Product(s) 

DODAF 

Model 

Reference 

Notes: 

Pre  •  system  Acquisition 

Integrated  Risk  List 

•  Cross  functional  list  of  risks  compiled  across  integrated  product  team 

Living 

Document 

Consolidated 

Risk  List 

FFP-IA 

Integrated  Risk  Plan 

•  Documentation  outlining  the  program's  risk  posture  and  threshold's 
for  reporting  and  mitigating  risk 

Initial 

Delivery 

Consolidated 

Risk  Plan 

FFP-IB 

Schedule 

•  Program  Driving  Schedule  Requirements 
-  Key  schedule  driven  technical  decisions 

•  Giver/receiver  relationships  that  span  different  program  elements 

Living 

Document 

Integrated 

Milestone 

Schedule 

PV-2 

Critical  System  Requirements 
Capabilities  /  Constraints  /  Outcomes 

•  Identify  required  program  outcomes  /  measures  of  effectiveness 

-  How  residual  capability  may  be  used  if  deemed  successful 

-  Communicate  aspects  of  the  mission  that  must  be  adhered  to  and 
cannot  be  traded  within  the  project 

Initial 

Delivery 

Mission  Plan 

AV-1 

Organizational  Roles /Boundaries 

•  Establish  lines  of  authority 

•  Highlight  system  boundaries  that  will  require  interface  control 
documentation  to  be  developed 

•  Delegate  project  roles  and  responsibilities 

Initial 

Delivery 

Mission  Plan 

OV-1 

OV-4 

Design  Standards  and  Life  Requirements 

•  List  of  regulatory  standards  that  program  is  required  to  comply  with 

•  Understanding  of  nominal  SC  design  life  and  risk  classification  (i.e. 
Class  A,  B,  C...) 

•  List  of  any  international  treaties  that  may  affect  program  decisions 

•  List  of  applicable  technical  standards 

Initial 

Delivery 

Mission  Plan 

STDV-1 

Critical  Program  Documentation 

•  Identify  required  documentation/  information  /models  from  various 
system  developers 

-  Highlights  the  how  many  iterations  are  planned  throughout  the 
document  lifecycle 

•  Identifies  delivery  dates  for  all  information  among  stakeholders 

Living 

Document 

Program 

Documentation 

Maturity  Matrix 

FFP-2 

Note  1:  This  needs  to  be 

a  consolidated 

government  owned 
product  that  isinclusive 

of  all  mission  areas 

Open  System  Trades 

•  Description  organized  by  subsystem  of  open  design  trades  and 
decisions  that  need  to  be  completed 

•  Each  trade  should  have  an  owner  and  associated  due  dates  that  are 

aligned  with  program  constraints 

Living 

Document 

Trade  / 

Decision 
tracking  matrix 

FFP-5 

Concept  Refinement 

Integrated  Risk  List 

-  Cross  functional  list  of  risks  compiled  across  integrated  productteam 

Living 

Document 

Consolidated 

Risk  List 

FFP-IA 

Schedule 

-  Program  Driving  Schedule  Requirements 

-  Key  schedule  driven  technical  decisions 

-  Giver /receiver  relationships  that  span  different  program  elements 

Living 

Document 

Intgrated 

Milestone 

Schedule 

PV-2 

Critical  System  Requirements 
Capabilities  /  Constraints  /  Outcomes 

-  Identify  required  program  outcomes  /  measures  of  effectiveness 

-  How  residual  capability  may  be  used  if  deemed  successful 

-  Communicate  aspects  of  the  mission  that  must  be  adhered  to  and 
cannot  be  traded  within  the  project 

Final  Delivery 

Mission  Plan 

AV-1 

Organizational  Roles /Boundaries 

-  Establish  lines  of  authority 

-  Highlight  system  boundaries  that  will  require  interface  control 
documentation  to  be  developed 

-  Delegate  project  roles  and  responsibilities 

Final  Delivery 

Mission  Plan 

OV-1 

OV-4 

Required  Standards,  Design  Life 
Requirements 

-  List  of  regulatory  standards  that  program  is  required  to  comply  with 
•  Includes  Preliminary  LV  Environments  and  Loads 

-  Understanding  of  nominal  SC  design  life  and  risk  classification  (i.e. 

Class  A,  B,  C...) 

-  List  of  any  international  treaties  that  may  affect  program  decsions 

-  List  of  applicable  technical  standards 

Final  Delivery 

Mission  Plan 

STDV-1 

This  should  be 
coordinated  w/  external 
agencies  to  ensure 
completeness 

Requirements  Functionally  allocated 
and  derived  for  each  subsystem  and 
component 

•  System  Developers  repsonse  to  the  Technical  Requirements 

Document 

-  Identifies  how  requirements  will  be  allcoated  among  various  systems 

-  Highlights  functional  responsibility  for  each  subsystem 

•  Provides  critical  data  regarding  system  boundaries  and  interfaces 

Final  Delivery 

SV  Requirments 
Specification 

FFP-4 

Typically  delivered 
leadinguptoSRR/ 
reference  DISA  DID 

SV  Technical  Requirements 

Documentation 

•  Complete  list  of  performance  requirements  for  the  Space  System 

•  Delivered  by  the  government  to  the  contractor/ agency  responsible 
for  space  vehicle  design,  development  and  integration 

Initial 

Delivery 

SV  Technical 

Requirements 

Document 

FFP-3 

Open  System  Trades 

-  Description  organized  by  subsystem  of  open  design  trades  and 
decisions  that  need  to  be  completed 

-  Each  trade  should  have  an  owner  and  associated  due  dates  that  are 

aligned  with  program  constraints 

Living 

Document 

Trade  / 

Decision 
tracking  matrix 

FFP-5 
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Mission  Phase 

Relevant  Architecture  Irtfo’mation 

Purpose/ Function 

Maturity 

Product(s} 

DODAF 

Model 

Refererxe 

Notes: 

Preliminary  System  Design 

Detailed  Design 

Integrated  Risk  List 

-  Cross  functional  list  of  risks  compiled  across  integrated  product  team 

PDR  Delivery 

Consolidated 

Risk  List 

FFP-IA 

Operational  Environment 

-Matrix  documenting  how  test  requirements  that  have  been  levied  are 
satisfied  with  test  (at  both  the  component  and  system  levels) 

-  Identification  of  the  method  that  will  be  used  to  verify  the 
requirement 

-  Identification  of  any  potential  non-conformances* 

Initial 

Delivery 

Environmental 

Test 

Verification 

Matrix 

FFP-7 

This  will  show  the 
capability  of  the  SV  to 
withstand  various 
environments  (i.e.  launch 
vehicles) 

System  Interface  Control  Documentation 

-  This  will  be  a  suite  of  documents,  the  mission  plan  should  identify 
critical  system  boundaries  that  reuqire  a  formal  interface  control 
document 

-  Minimum  Criteria;  SV  -  Ground  and  Payload  to  SV ICD  initial  drafts 
must  be  complete 

-Other  pertinent  ICDs;  LV  -  Spacecraft,  Component  interface  ICD 

Initial 

Delivery 

Interface 

Control 

Documentation 

SV-l/SV-6 

Schedule 

-  Program  Driving  Schedule  Requirements 

-  Key  schedule  driven  technical  decisions 

-  Giver/receiver  relationships  that  span  different  program  elements 

Living 

Document 

Intgrated 

Milestone 

Schedule 

PV-2 

System  /  Sub-system  Design 
Specifications 

-  Partial  Preliminary  understanding  of  system/subsystem  design 

-  Allocation  of  required  system  functions  to  configuration  items 

-  Demonstration  of  how  system  requirements  are  satisfied  by  design 

Initial 

Delivery 

PDR  Design 

Presentation 

SV-5 

Open  System  Trades 

-  Desription  organized  by  susbsystem  of  open  design  trades  and 
decsions  that  need  to  be  completed 

-  Each  trade  should  have  an  owner  and  assocaited  due  dates  that  are 
aligned  with  program  constriants 

Living 

Document 

Trade  / 

Decision 
tracking  matrix 

FFP-5 

Technical  Performance  Measures 

-  Demonstrate  design  peformance  to  critical  program  requirements 
outlined  within  the  requirements  document 

Initial 

Delivery 

Technical 

performance 

budget 

SV-7 

Values  in  the  budget 
should  be  compared  to 
industry  standards  for  a 
given  maturity  in  the 
devleopment 

System  Design  Specifications 

-  Detailed  description  of  "to  be"  system/subsystem  design 

-  Allocation  of  required  system  functions  to  configuration  items 

-  Demonstration  of  how  system  requirements  are  satisfied  by  design 

Final  Delivery 

CDR  Design 

Presentation 

SV-4/SV-5 

Note:  Reference  Lesson 

11-  Need  to  look  at  some 
views  and  diagrams  that 
would  be  useful  for  every 
subsystem 

Integrated  Risk  List 

-  Cross  functional  list  of  risks  compiled  across  integrated  product  team 

CDR  Delivery 

Consolidated 

Risk  List 

FFP-IA 

Operational  Environment 

-Matrix  documenting  how  test  requirements  that  have  been  levied  are 
satisfied  with  test  (at  both  the  component  and  system  levels) 

-  Identification  of  the  method  that  will  be  used  to  verify  the 
requirement 

-  Identification  of  any  potential  non-conformances* 

Final  Delivery 

Environmental 

Test 

Verification 

Matrix 

FFP-7 

Note:  previous  delivery 
should  have  defined  how 
requirements  would  be 
satisfied  for  long  lead 
components.  This 
delivery  would  address 
all  remaiingcompents 
and  system  levels 

System  Interface  Control  Documentation 

-  This  will  be  a  suite  of  documents,  the  mission  plan  should  identify 
critical  system  boundaries  that  reuqire  a  formal  interface  control 
document 

-  Minimum  Criteria;  SV  -  Ground  and  Payload  to  SV  ICD  initial  drafts 
must  be  complete 

-Other  pertinent  ICDs;  LV  -  Spacecraft,  Component  Interface  ICD 

Final  Delivery 

Interface 

Control 

Documentation 

SV-l/SV-6 

Schedule 

-  Program  Driving  Schedule  Requirements 

-  Key  schedule  driven  technical  decisions 

-  Giver /receiver  relationships  that  span  different  program  elements 

CDR  Delivery 

Intgrated 

Milestone 

Schedule 

PV-2 

Integration  Prodcution  Plan 

-  List  of  all  components  under  procurement  and  their  expected  and 

need  dates 

-  List  should  include  all  piece  parts,  miscellaneous  mat'Is,  connectors 
and  required  ground  support  equipment 

Initial 

Delivery 

System  Parts 

List 

FFP-6 

Technical  Performance  Measures 

-  Demonstrate  design  peformance  to  critical  program  requirements 
outlined  within  the  requirements  document 

Final  Delivery 

Technical 

performance 

budget 

SV-7 

Values  in  the  budget 
should  be  compared  to 
industry  standards  for  a 
given  maturity  in  the 
devleopment 

Open  System  Trades 

-  Desription  organized  by  susbsystem  of  open  design  trades  and 
decsions  that  need  to  be  completed 

-  Each  trade  should  have  an  owner  and  assocaited  due  dates  that  are 
aligned  with  program  constriants 

Living 

Document 

Trade  / 

Decision 

tracking  matrix 

FFP-5 
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Appendix  E:  Acronyms 


AFI 

Air  Force  Instruction 

AFRL 

Air  Force  Research  Laboratory 

AFSPC 

Air  Force  Space  Command 

AFSPCI 

Air  Force  Space  Command  Instruction 

C4ISR 

Command,  Control,  Communications,  Computers, 

Surveillance  and  Intelligence  Architecture  Framework 

CDRL 

Contract  Deliverable  Requirements  List 

COTS 

Commercial  ”  Off  the  Shelf’ 

DID 

Data  Item  Description 

DoD 

Department  of  Defense 

DoDAF 

Department  of  Defense  Architecture  Framework 

MIL-STD 

Military  Standard 

SE 

Systems  Engineering 

SGLS 

Space  -Ground  Link  System 

S&T 

Science  And  Technology 
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